zl sub not reporting a number that is in the list
I have a float number and a list of floats and I send the number and the list to the zl.sub to see where the number is located in the list and the zl.sub tells me it is NOT in the list even though it obviously is.
Then I copy the message with the EXACT same number and the zl.sub now tells me the correct location of the number in the list.
What can cause this type of behaviour???
See Less
the problem seems to be that if you type a float with over 6 decimals into a message box it will somehow remember all the decimals of the number but display only six of them and when you compare that to a same looking number it is not the same. is there a way to "cutoff" all the invisible decimals?
Using an equal operator between two floating point numbers is often dangerous. One would think that using a [round 0.000001] could work, but it's not that simple... The beauty of floating point numbers & computers...
Putting [sprintf %.6f] after the float number seems to help for this situation.
But it is kind of funny not to know what number you are actually getting. Is there some documentation on this?
Well, comparing floating point numbers is tricky, not just in Max... Best approaches include redesigning to avoid direct comparison of floats, or if you really want to compare floats, you could an equality function with a built-in tolerance (which is pretty much what you do with round, or sprintf rounding). If you google for the topic, you'll find interesting information, with varying degrees of nerdiness. And if you search this forum, you will also find lots of discussions of this topic!
https://bitbashing.io/comparing-floats.html
https://en.wikibooks.org/wiki/Floating_Point/Epsilon
thank you will check it out