Sometimes when I type a value into a field, like 2, it turns into 2.000000000001. I understand there is a limit to the number of digits in floating point number but I am just typing an number without any calculations. I am curious about reason behind this.

The only time I found this a problem was when I was trying to find out points with certain u value “0.7382”, which was shown on the geometry spreadsheet. I was just using an “if” statement to check if the value was exactly equals to “0.7382” but it returns nothing. I later suspected that there were some digits hidden behind it so I multiplied it by 10000 then converted it to integer for comparison and it worked. Does anyone got a better way to compare values?

It may not be the answer you hope for, but float issues and float precision issues will be with you forever. It's best to change the way to do things and NOT compare against 0.7382 for example, but >=1 or so, depending on the context.

benC
I was just using an “if” statement to check if the value was exactly equals to “0.7382” but it returns nothing.

Never, never do that, never try to compare two float to see if they are equal: it will never work.
I had the same problem (see here [sidefx.com]) and what you have to do instead is compare a value (the value you are looking for) to a range, with your example you can write the following code:

Or also:

So basically to get that to work you dont check if the two values are equal, but if the two values are more or less close

Also,…it's not a Houdini ‘thing’. It's with how hardware treats ‘floats’.

This link is but once example of the topic and you may want to do some of your own searches to get a better understaning:

https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html [docs.oracle.com]

When you have a better understanding, then you will be able to write the code in a way that serves your purpose like the suggestion SteN gave.

Great Answers! Thanks everyone

It was working when I use blast @uv==0.7382 to isolate the points but not "if(@uv==0.7382)" in attribute wrangle. Anyone know the reason behind this?

The group syntax for @foo==bar uses a tolerance, while VEX doesn't.

You could do a string compare to get some tolerance. I think %0.6g seems to match the geometry spreadsheet.

Converting a float to a string is going to be extremely slow though, compared to more direct methods using tolerances like those mentioned higher up in this thread.