I would say its because you cannot express the ratio 4/3 exactly as a decimal or as a binary. (1.333333 is not the same number as 4/3). Maybe someone who knows more about how 32-bit floats are represented in max could shed light on this

Hello Terry, thank you for your reply. I understand the "problem", but who to trust if we can not count on expr :)

The reason for this is that the number displayed in the message box as the output of expr is being truncated. When we look at the float in a float object set to 10 decimal places we can see that the value is not equal to 1.333333, therefore zl, == and sel are all behaving correctly.

To work around this, you could use if to compare the float to the original calculation, or you could convert the float into a symbol and then use zl compare or select. These methods are shown in the patch below.

@LLT: You can trust expr (to the limits of 32-bit floating point). It's typing numbers into object boxes you need to be wary of.

Basically, you cannot reliably type floating-point values into object boxes and compare these against calculated values. The calculated values is not restricted to [expr] objects; all the arithmetic objects (plus/minus/times/divide/modulo/etcetc.) will have the same kinds of behavior.

If you want reliable comparisons, use integers. If you insist on typing floats into object and message boxes, the only accurate ones are those that are "round" in binary: sums of 1/2, 1/4, 1/8, 1/16, etc.

so all you have to do is write "4/3" instead of 1.333333.

Hello everyone, thank you for your answers. LLT