number_to_string cannot handle "float" correctly.

[g2m.agent]

I know that there is always an accuracy problem, but I prefer the behavior of the node to be consistent with the value I see.

[Grahame_Fuller]

This is how floating-point values work -- it's not specific to Bifrost.

Floating-point values cannot represent all decimal values exactly -- there are gaps. In this instance, .370000005 actually is the decimal representation of the closest floating-point value to .37. In the UI, the float value is rounded for display but the string is not.

If you wanted to, you could use the string manipulation nodes to truncate that string to the number of decimal places you want. Rounding is also possible, but a bit trickier. However in either case, the string would no longer be the exact decimal representation of the actual float value that was converted to a string.

Hope that helps,

gray

[g2m.agent]

How float work is not important to the user.

I think that since users convert float into text, its meaning is by no means for precise calculations, but just for "show". for human to read, not to calculate. what is the point of showing its full accuracy? If you want to check the float precision, wouldn't it be more reasonable to put it in watchpoint.

I strongly recommend modifying how number_to_string works. I really can't understand the design intent of this node and the working scenario.

[Grahame_Fuller]

I beg to differ -- how floats work is sometimes very important to users.

Comparisons are just one example (see Comparing Floating Point Numbers, 2012 Edition). This is why there is an almost_equal node.

The number_to_string node is just one of a set of basic conversion nodes for generic use. One possible use is to store string properties to help with debugging. In such a scenario, knowing that a value is actually 0.370000005 and not 0.37 might be critical.

Cheers,

gray