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.
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.
