Wrapping operations in SetPrecision reveals a very small delta between the two values.

It's as though, despite what I think the behavior should be, that tiny delta is still affecting the = comparison operation, unless some extra action happens which causes FMP to cast the values to strings/text.

That's just speculation, of course, and, I'll add: It does not feel consistent with what I am used to, nor what I would expect...

@steve_ssh is onto something. For now, if you want them to be equal, you need to compare them using Round, with a precision set to 17 or below. Precision above 18 makes them inequal.

I do not use SetPrecision often, and would need to dig deeper to figure what happens here.

The basic math would want the operations to cancel each other, but FileMaker applies them in sequence, and it seems something is kept along the way, something FileMaker is not outputting in the result it gives back.

I know that dividing by prime numbers will cause rounding errors, so I expected to see something funky happening.

I tried SetPrecision at a variety of levels: 16, 32, 48, 56, 64. At 56 I saw the recalc value expressed as 24.99000000000000000000000000000000000000000000000000000001. For all the other values, the outcomes were expressed as two decimal places.

The big difference was that the equality test was true when I used SetPrecision (except at 56) to perform the calculations. Even though the visual output was identical. I think this is pointing toward your speculation that the fractional difference is being preserved somewhere.

As GetAsNumber comparison generates a false result, which is what we see in the first example. And because the GetAsText comparisons all generate a true result I don't think that FMP is casting the values to strings. I think that it is treating them as numbers.

You are right that forcing the expression engine to use a specific level of rounding, via Round or SetPrecision, does affect the outcome. Even so, there is a trick in that.

The output generated SetPrecision differs at each level. At some higher levels it will resolve to two decimal places.

And the output of Round only affects the number if it needs to be truncated.

Here is x with 48 decimal places:

x = 24.989999999999999999999999999999999999999999999999
Round ( x ; 48 ) => 24.989999999999999999999999999999999999999999999999

Here is x with 49 decimal places:

x = 24.9899999999999999999999999999999999999999999999999
Round ( x ; 48 ) => 24.99

and at 3 decimal places:

round( 24.989 ; 4 ) => 24.989

And here is the calculation engine working at several decimal places beyond the limit used in the SetPrecision function

Sharp eyesight @JasonMark! Fortunately (?) the equation editor isn't case sensitive.

The basic problem is that we when we assign a value to a variable the onscreen representation of that value is misleading.

In this case the variable is storing an infinite fraction, 24.9899999999...... truncated at 16 decimal places. However, when I ask what the value is I am shown 24.99. When I use SetPrecision to show the value it continues to show 24.99 - sometimes even when I ask for precision at the maximum of 400 decimal places.

The flow-on effect is that comparisons using = , < , and > will produce the wrong result. It is possible that it will create problems.