Hello, I noticed that in the parameters pane, when I type in for example “2.5” often I get “2.4444449”.
It doesn't happen all the time though.
But is there a way to prevent this in all cases?
Thanks
Gz

This bug is still here since 2018 and probably before!! Nobody else finds this annoying?

It's not a bug !

Found on the web (type "floating point precision error" on Google) :

"It's a problem caused when the internal representation of floating-point numbers, which uses a fixed number of binary digits to represent a decimal number. It is difficult to represent some decimal number in binary, so in many cases, it leads to small roundoff errors"

Sorry but I still don't understand why, when I type in 2.5, it converts to 2.4444449

Grendizer
Sorry but I still don't understand why, when I type in 2.5, it converts to 2.4444449

because 2.5 doesn't exist

Oh come on don't give me this typical Houdini Geek answer. When I type in 2.5 in Photoshop, Word, Candy Crush, ANY APP, I get 2.5, NOT 2.444444449. Why is Houdini not able to correctly round values like any other app???

Numbers are not stored in decimal but in binary, and with limited precision they might not always line up to round decimal numbers. Houdini displays the number it holds in memory instead of a rounded version of it, as other software might.

Grendizer
Oh come on don't give me this typical Houdini Geek answer. When I type in 2.5 in Photoshop, Word, Candy Crush, ANY APP, I get 2.5, NOT 2.444444449. Why is Houdini not able to correctly round values like any other app???

click the little thingy with the parm name on it to switch it back to normal display mode. When the parm is in true display mode, it will show the actual value. In 32bit binary floating point numbers, 2.5 literally doesn't exist, it's impossible to represent exactly. Apps may print it out nicely, but Houdini can display it either way.

Thanks Jsmack. I thought this button was to switch between expressions and expressions results , or between data type and value. But this works.
I still don't understand why you say "2.5 doesn't exist" but I'll stop bugging you

2.5 should be exact in binary representation (like 0.5/0.25/0.75) but not (2.1/2.6/0.1) for example, but there can be errors if 2.5 is the result of a calculation.

Grendizer
Thanks Jsmack. I thought this button was to switch between expressions and expressions results , or between data type and value. But this works.
I still don't understand why you say "2.5 doesn't exist" but I'll stop bugging you

https://www.mathworks.com/help/symbolic/choose-symbolic-or-numeric-arithmetic.html [www.mathworks.com]

Symbolic math results are exact but I doubt SESI would implement it for performance reasons and more memory usage.

Hey Aizatulin
Well no, in my case 2.5 is NOT the result of a calculation, it's just values that I type in, on some objects, in the transform tab at the /obj level, or in the base node in the geometry level. At the beginning all is fine and when I type "2.5" I can see "2.5".
Then when I go back to the same node, the value is converted to "2.499999999".
So the problem is not even a rounding problem, 2.499999999 is lower than 2.5, so the real problem is that the value is CHANGED.
The same happens with rotations. Even if I don't rotate an object , when its transform is 0, after a while Houdini keeps putting things like "-1.73472e-18". These values are so small they're equivalent to 0, but why does Houdini replaces "0" by "-1.73472e-18"?
THIS is what I don't understand, and no technical math page will put my mind at ease about this. I still think it's a bug.

I can't verify this by my side, if I turn on full precision on in the spreadsheet 2.5 is still 2.5, but 2.1 turns to 2.0999999046325684, which is what I was expecting. Even if you rotate a vector by angle 0, the components remains the same (but if i rotate by 2*pi, I will get -1.7484555314695172e-07 for one component). This seems to be a value around the machine constant of single float precision. I don't know how you get your values, maybe you can share your file.

Here is my example.

Grendizer
Well no, in my case 2.5 is NOT the result of a calculation, it's just values that I type in, on some objects, in the transform tab at the /obj level, or in the base node in the geometry level. At the beginning all is fine and when I type "2.5" I can see "2.5".
Then when I go back to the same node, the value is converted to "2.499999999".
So the problem is not even a rounding problem, 2.499999999 is lower than 2.5, so the real problem is that the value is CHANGED.
The same happens with rotations. Even if I don't rotate an object , when its transform is 0, after a while Houdini keeps putting things like "-1.73472e-18". These values are so small they're equivalent to 0, but why does Houdini replaces "0" by "-1.73472e-18"?
THIS is what I don't understand, and no technical math page will put my mind at ease about this. I still think it's a bug.

are you sure you put in 2.5? it turns out that 2.5 is an exact float number, so it should always be 2.5
Sometimes manipulating the handles interactively can result in some precision loss due to trig math being used.

Rounded view:


Full precision view:

Well 2.5 was just an example. Perhaps this happen only on numbers that Aizatulin was telling about : 2.1 2.6 0.1 ...
But I still don't understand why these numbers don't stay the same as I entered. Even if I don't manipulate the handles, 2.1 turns to 2.1000000000000001, which is not the same VALUE.
Same thing with transforms at 0 that turn to microscopic values.

Grendizer
Well 2.5 was just an example. Perhaps this happen only on numbers that Aizatulin was telling about : 2.1 2.6 0.1 ...
But I still don't understand why these numbers don't stay the same as I entered. Even if I don't manipulate the handles, 2.1 turns to 2.1000000000000001, which is not the same VALUE.
Same thing with transforms at 0 that turn to microscopic values.

If you order a pepsi at a restaurant that only sells coca cola, and they give you a coca cola, will you be surprised?