Right, I am encounter a very suck thing of float. I am doing a an output file that requirement of very very exactly value from canculation, but Max seem get round all float when display
For a simple example
a = -118.2584426
So you see in Listener Max return value -118.258 ??
And do a canculation and print them out
a = a + 2
print a
Then we got -116.258
So we get a float being round up , and because I need to output these value to file and an external application read them . So all these value go wrong and I get same value in my file like -116.258 with only 3 number after “.”
So how could we force Max to display more.
Thanks
even the formattedPrint can not help. I ‘ll give an example
real_long = -118.2584425 as float
formattedPrint real_long format:“0.20g”
this is result “-118.25844573974609” :bowdown:why it is different from my original number. I have tested many and it seems Max try to create his own number after 4 decimal digit
Another example
v = 0.0000000001522
formattedPrint v format:“0.50g”
and we get “0” as result :bowdown:
real_long = -118.2584425d0 --Double!
-118.258d0 --Note that MAXScript shows it short, but internally it is ok
formattedPrint real_long format:"0.20g" --so if you print it out, you get your long number:
"-118.2584425"
some funny result from Max
formattedPrint -118.11111111 format:”.15g”
“-118.111114501953”
formattedPrint -118.123456789 format:”.15g”
“-118.123458862305”
formattedPrint -118.01010101 format:”.15g”
“-118.010101318359”
So funny but I can not laugh now
I really get CRAZY now, I spend the whole day for writing an exporter for our project and algorithm is correct, but now the output number is totally wrong and cause model distord, wrong place !!!
Terrible, I sure after decimal point, only 6 number is correct, the other is A LIE make by MAX
D**M IT !!
I think what you’ve discovered is the inherent accuracy problem of using floating point numbers, it’s not Max’s fault.
I must say IT IS MAX! Because what I am doing is shifting the exporter script for Maya to 3DSMax, everything is white easy and simple, just replace maya code by Max code line by line and then finally I get the tool run
So with the same algorith, Max suck up the whole value.
I will show you desired value made by Maya
-118.2584426, 34.04741358, 8.42926266
-118.2584426, 34.04741358, 1.975621745e-015
-118.2585025, 34.0474742, 1.105462699e-015
-118.2584426, 34.04741358, 8.42926266
and what Max cause
-118.25844573974609, 34.047412872314453, 8.4292621612548828
-118.25844573974609, 34.047412872314453, 0
-118.25849914550781, 34.047351837158203, 2.6498702254684758e-007
-118.25844573974609, 34.047412872314453, 8.4292621612548828
So with me, only a very slightly shift in vertices will cause terribly issue, and because Max try to create his own number after 6 number after decimal point. All is WRONG!
I’m no expert with floating point stuff, but I don’t think you can accurately represent those numbers with single precision floats. :shrug:
sorry but what you mean "[u]accurately [/u]represent those numbers with single precision floats"
, I dont get this idea.. I just want to show Max has a limit with float calculation itself, not only display.. and this lead to simple incurate
Another example Max do wrong calculation
please let a = 1/3
formattedPrint a format:".15g"
we get a number like 0.3333334xxxxxx (not 0.33333333333)
copy this number and multiply it with 3
we get 1 again
so what s wrong with internal calculation of Max :shrug:
==========
So anyone has idea with this issue. or I just think up a SUPER STUPID way: be multiply the whole vertex position with 1000000 and then calculation on these number. And then make a function to seperate number base on this number and write them down into file. 🙁
But now… I am really afraid, if Max has problem with number exceed 1000000 (six zeroes before demimal point) :shrug:
Right, another, very FUNNY of 3DSMax, this case, too simple that I dont think it could be wrong, but Max do it wrong
Sorry but F*k up Maxscript! This issue, regard as UNACCEPTABLE for an application like Max
Because I am desperate of 0.00000xxxx thing. I convert it to a simpler number with few decimal after point.
a = 34.047413 as float
result: 34.0474
a *= 1000000 as integer
result: 3.40474e+007 ?? convert to float without asking me any thing?? why
a as integer
result: 34047412 ~> Funny hah :deal:
and this case is really more funny, anyone know what is DIFFERENT between 34 and 11 in Max :deal:, well 34-11 = 23 , a MAGICAL NUMBER so It will give you this magical result, um blah bah cucaracha, MAGIC HERE
a = 11.047413 as float
11.0474
a *= 1000000 as integer
1.10474e+007
a as integer
11047413 OuR MAGiC MAx KNOW HOW TO DO WITH NUMBER for amazing result
Bobo wrote a very detailed answer to how max deals with Float values a few weeks ago, worth looking up.
I make a search with Bobo as name and many keyword may has like decimal, float, formattedprint… etc but get no info
Moreover, I have make search through the forum for these kind of keyword but get no info before
so whats wrong with internal calculation of Max
The answer is nothing.
You cannot properly mimic real numbers with floating point numbers, what you are describing are rounding errors.
Max uses single precision floats internally which are good for about 6 digits of accuracy.
So when you store the real number 118.2584426 in max, it is rounded to a single precision float.
I must say, If, Max does the simple task of round up to 6 number as you said, the problem has been solve by multiply with 1000000 for every input data, then I will make function to seperate them into string and put to text.
Read my thread above and see example of 34 and 11 case, well they has ONLY 6 number after decimal and we get different data. The only explaination is another thread abover, when we declare a number as float, Max automatically interpolate some random number after 5 and 6 number after decimal, and cause wrong calculation.
If you dont believe my example, make a test and see it, unknown number [b]appear everywhere
[/b]PS: So the 34.047413 is interpolated as 34.04741287 so that s reason it come into 34047412 after multiply.