LoginLogin

Really Big Numbers

Root / Programming Questions / [.]

MinxrodCreated:
OK, so, I was trying to make a program that requires larger numbers than SmileBASIC supports naturally, like up to 20 or 100 digits. However, I couldn't remember SmileBASIC's max number, so I just started copy-pasting ?2*2*2*2*2*2*2*2*2*2*2*2*2*2*2*2*2*2*2 with more and more 2s. When I did this (In DIRECT MODE) I eventually got to this:
?2*2*2*2*2*2*2...*2*2*2
39614081257132169000000000000
OK
(That's 94 2*'s and one 2. 295) So, apparently SmileBASIC's DIRECT MODE can handle much more massive numbers, but with rounding errors (end digit 0 isn't normal on a multiple of two if you didn't realize that yet) Is this a bug or just a weird feature with not much use?

they probably run the operation 2*2... and let it overflow infinitely into an "array" of bigints, with an overflow/carry flag triggering adding into the next array element and they do the same with that element and so forth. I don't know how they'd run the binary to decimal conversion there I'd be lost, but I'll bet they only take the top 64 bits or so (either before or after decimal conversion) and that is what gets padded with the 1's 10's 100's column... as in.. we are actually seeing. a 64bit number * 10^10th, which is probably why we are seeing 3,961,408,125,713,216,900 in the "0_000_000_000" column...10 trillions column? as in take off "0000_0000_00" 0's and that is probably the number sb had. we have no access to an overflow flag, but you can do bit by bit addition into a 3rd variable and detect the final bits overflow that way perhaps....

The 'numbers that SmileBasic supports naturally' are the integer data type (-2,147,483,648 to 2,147,483,647) and floating-point (probably IEEE754 64-bit, which has 53 bits of precision for most of its range - about 15 digits, and a maximum of about 10^308). These are common, standard data types.

interestingly enough str$() of a super large number that will display with lots of 0's such as above comes back to me as 3.96141e+2811 ...when the number was pow(2,95) now I divide that back by 2 in a for loop 95 times and get 1 back even tried it with 2.1..still get my 1 back..so its handling the big ints. just can't spit them back in a friendly way str$(number) get cuts to e+2811 whatever and the PRINT number version sucks too...hex only goes out to 8 digits. did you try manual decimal conversion? of course that isn't take into effect floating exponents and I assume since I was using power of 2 my results are super biased and didn't try dividing by different mantissa(whatever) based numbers or..whatever that means :( try pow(2,52) print it, then add one and print it...its one more...but any higher powers like 53 54 55 and the amount to add to see a changegoes up...binary like. so at pow(2,53)+2 to see a change +1 triggers no change as far as print is concerned..but do something like add 1, subtract 1 then do your division and the precision is there. I haven't tested decimal precision going down..but the 2.1 seems to work as well. so it seems PRINT has only 52(53?) bits of precision to it and the rest is padded 0 at least on the big integer side. I wonder if floats are really just integer arrays, with an internal push as it overflows its range? so to recap ?POW(2,52)+1 is the last time you'll get an odd number out and ?POW(2,57) is when the 0's start padding in.

POW(2,52)+1 is the last time you'll get an odd number
I think, (POW(2,53)-2)+1 will give you the largest odd number. And using powers of 2 is definitely favouring the system. POW(3,34) is calculated as 16677181699666568 (about 1.6e+16, much less than 3.9e+2811 of POW(2,95)): an even number, obviously wrong.

POW(2,52)+1 is the last time you'll get an odd number
I think, (POW(2,53)-2)+1 will give you the largest odd number. And using powers of 2 is definitely favouring the system. POW(3,34) is calculated as 16677181699666568 (about 1.6e+16, much less than 3.9e+2811 of POW(2,95)): an even number, obviously wrong.
so that is what icode does lol, yup POW(2,53)-1 yeah, I coulda did a lil bit more and said that 2^52-2^53 is the last time +1 works. I think it works in the whole range. but is 3^34th larger than 2^53rd and will no longer be odd? it is larger, and is "odd" number but "even" in PRINT representation cause POW(2,53) is where odd numbers get dropped. it isn't the exponent that matters, sorry if I implied all base numbers were fine with those exponents..its the actual final value that throws PRINT off.

I may be wrong, but I believe SmileBASIC works with math as real-type by default, unless it finds enough info to assume integer type (&H literals, using DIV, etc.) This is probably what's going on here, as real-type numbers can get REALLY big. From what I can gather, the real type numbers are just IEEE doubles like Square said. And the bigger a double gets, the less precise it gets. This is probably normal behavior. EDIT: To prove my point, if you do A#=POW(2,95) and print A#, you get the same result as the OP. Things are working as intended.