num2text() will fail to show the actually-stored floating point value for sufficiently-large numbers. Depending on the value, these will either be rounded off to a power of ten, or num2text() will refuse to display the full value no matter what precision you specify.
Numbered Steps to Reproduce Problem:
Refer to the code below.
Code Snippet (if applicable) to Reproduce Problem:
mob/Login()
var/i = 1
for(var/j = 0 to 70)
if(j > 56)
world << "2**[j] -> [num2text(i, 5000)]"
i *= 2
Expected Results:
The actual floating point values, shown below.
2**57 -> 144115188075855872 2**58 -> 288230376151711744 2**59 -> 576460752303423488 2**60 -> 1152921504606846976 2**61 -> 2305843009213693952 2**62 -> 4611686018427387904 2**63 -> 9223372036854775808 2**64 -> 18446744073709551616 2**65 -> 36893488147419103232 2**66 -> 73786976294838206464 2**67 -> 147573952589676412928 2**68 -> 295147905179352825856 2**69 -> 590295810358705651712 2**70 -> 1180591620717411303424
Actual Results:
2**57 -> 144115188075855870 2**58 -> 288230376151711740 2**59 -> 576460752303423490 2**60 -> 1152921504606847000 2**61 -> 2305843009213694000 2**62 -> 4611686018427387900 2**63 -> 9223372036854775800 2**64 -> 18446744073709552000 2**65 -> 36893488147419103000 2**66 -> 73786976294838206000 2**67 -> 1.4757395258967641e+020 2**68 -> 2.9514790517935283e+020 2**69 -> 5.9029581035870565e+020 2**70 -> 1.1805916207174113e+021
Workarounds:
Nothing obvious, except using a library that offers higher precision than what BYOND offers by default. But for floating point arithmetic, there's not (to my knowledge) really anything else available at the moment.
