✅ upper bound of BigInteger Type
The docs say there is no upper bound for the BigInteger type, it is only dependant on our hardware.
That answer is not really enough for me to understand so I thought it would help me understand if I calculate the upper bound for lets say 8 GB of RAM available / free .
I've come up with different approaches to calculate this and I'm afraid all my calculations are wrong.
if anyone could please provide a correct calculation for this i would be very thankful.
An example of what I've tried:
8GB Ram = 8 * 1024^3 bytes = 8.589.934.592 bytes
thus we can store 2.147.483.648 int32s or 1.073.741.824 int64s?
so we can store a number up to
2^(2.147.483.648*32) or 2^(1.073.741.824*64) in the BigInteger?30 Replies
BigInteger internally uses a uint[] to store its bits (along with a bool indicating the sign). The maximum length of an array is 2147483591, and a uint is 32 bits. This means that the maximum value of BigInteger is 2 ^ (2147483591 * 32) - 1.
Which is, for all intents and purposes, infinite2147483591 is suspiciously close to 2147483648 what i had in my calculation but not quite the same, how comes they are so close but still different?
how do you calculate the max length of an array?thinker227#5176
REPL Result: Success
Result: int
Compile: 320.047ms | Execution: 23.720ms | React with ❌ to remove this embed.
I think this is universal, although it might be dependent on hardware
that is, if you can manage to allocate an array that big
you helped me understand a little better, thank you very much
np 
Just watch out for x86 and those large length arrays
The upper bound for
BigInteger used to be Array.MaxLength but was changed in .NET 7 to instead be no more than 2.14 billion bits, which means the largest BigInteger is now just shy of 256MB in size
To elaborate, this means the maximum BigInteger is a value that is less than around 2^2147483647, which would contain 6.46 * 10^8 decimal digitswhat would happen when that max value is reached?
This is an extraordinarily large number and once you start getting that large, you're going to run into other practical limitations on your system and the time requirements needed to process the value. You'll also see negative impact to the GC and general system, hence the limitation
You should typically see an
OverflowException if you end up with something that large. Depending exactly what is being done, however, you could also see OutOfMemoryException or ArgumentOutOfRangeExceptionif I'm using .Net 6 (which I am) i can store a number up to
2 ^ (2147483591 * 32) - 1 then using BigInteger type?"yes", but you'll run out of memory or hit other limitations well before that
you'll also find that some APIs don't behave well in general
Keep in mind you need around
10^82 to represent every atom in the known universe
and even with the limit on .NET 7, we're allowing up to 10^646456992
you're likely doing something very wrong or very domain specific if you're hitting these limitsassuming i have 8 GB memory free, how big of a number can I store in the BigInteger without reaching an OutOfMemoryException tho?
in .Net 6
Well, those 8 GB would be partially used up by other things, so I assume you mean 8 GB dedicated to just one BigInteger
Which is a pretty crazy concept lol
yep
It's impossible to say due to other mechanics that are impacted in the system
It's not something you should really be concerned about, and you shouldn't ever hit even the 256MB limit in practice from .NET 7
You're talking about representing numbers that are so far outside the realm of the universe
that there is no practical or even theoretical good use for them
(because they're significantly beyond the entropy limits of the universe)
I see, thank you very much for taking your time 🍻
Clicker games:
I think your browser would crash if you tried to make an 8GB number 😄
I mean i knew that it would not have any valid use case it's just studying after all 😄
Just wanted to make sure I iterated it. Get a lot of people who like to complain about things like this
they think that because it could be supported, it should be supported, even if there isn't a use
true that
u dont wanna be 1000 steps ahead of the 
huh, that's interesting.
we needed to have a well-defined contract for generic math
and we didn't want to require handling shifting more than 2 billion bits for a scenario that was impractical
and same in general for things like copying out the backing bytes for the data of a number, etc
shifting more than 2 billion bits
things you have to consider when designing such APIs 😉
we're allowing up to 10^646456992👀
that's 2.14 billion bits, for reference
you really don't want to even go that large
you'll likely fill your needs much smaller
Was this issue resolved? If so, run
/close - otherwise I will mark this as stale and this post will be archived until there is new activity.