Our knowledge of mathematics is a lie!

Author Topic: Our knowledge of mathematics is a lie!  (Read 974 times)

Fellow Blocklanders - as you no doubt know, all numbers have a maximum precision of six decimal digits.  All attempts to calculate values beyond this cosmic limit are doomed to failure.  This is the basis of all mathematics, and we have based our entire society on this well-known maximum limit.  Some fools have dared to go beyond this limit, but they were derisively dismissed as lunatics with no regard for the natural order of things.

But it is all a lie!  The underlying fabric of reality we all live within allows a maximum of up to sixteen decimal digits of precision!  Our entire knowledge of mathematics is a baseless lie!  We have been following arbitrary limits imposed by an unseen force!



All jokes aside, TorqueScript implements double-precision floating-point mathematics in the underlying engine code; the full precision is simply truncated to six decimal digits when converting to a string or crossing function calls.  Try the following code snippets in the console - the "Expected Result (6 digits)" is what we'd expect to get if the numbers were truncated to 6 digits before being passed into mathematical operands.

Code ExampleExpected Result (6 digits)   Expected Result (Single)   Expected Result (Double)
echo((1+mPow(2,-23))-1);01.19209289...*10-71.19209289...*10-7
echo((1+mPow(2,-52))-1);002.22044604...*10-16
echo(mPow(2,1023));8.98847e+307Positive Infinity8.98846567...*10307
echo(mPow(2,127)+mPow(2,125));2.12676e+382.12676479...*10382.12676479...*1038
echo((mPow(2,127)+mPow(2,125))-2.12676e+38);   04.867778...*10324.79325586...*1032
echo(1/3-0.333333); //Ipqµarx03.476938...*10-73.33333333...*10-7


So now the only question remaining is how to utilize the full precision of the underlying doubles without being truncated to six decimal digits.
« Last Edit: May 17, 2015, 01:58:25 PM by Xalos »

You can also do another test to prove this. Let's say for a moment that we're only dealing with single precision floats. Then we should only expect about 7-8 digits of precision max.
But, if we, were to say, divide 1 by 3, and then subtract .333333 (6 digits of precision that we can see directly) we should expect only 2 more digits right?
==>echo(1 / 3 - 0.333333);
3.33333e-007


Nope. We get 6 MORE digits of precision. Doubles confirmed.

Actual confirmation: the TGE source uses F64 values for torkscript

Actual confirmation: the TGE source uses F64 values for torkscript
It also uses S64 for integers... but we can't access the full 64 bit range of integers! Why's that I wonder?

It also uses S64 for integers... but we can't access the full 64 bit range of integers! Why's that I wonder?
Are you sure? Near the top of compiledEval.cc, we have:

F64 floatStack[MaxStackSize];
U32 intStack[MaxStackSize];
StringStack STR;

Are you sure? Near the top of compiledEval.cc, we have:

F64 floatStack[MaxStackSize];
U32 intStack[MaxStackSize];
StringStack STR;

Weird, for me it shows this


Oh well, nevermind.

But it is all a lie!  The underlying fabric of reality we all live within allows a maximum of up to sixteen decimal digits of precision!  Our entire knowledge of mathematics is a baseless lie!  We have been following arbitrary limits imposed by an unseen force!
there's a pun here, i'm sure of it