When marking equations, floating point error can break equality

[christianp]

This question demonstrates the problem and a couple of solutions.

When the answer to a mathematical expression part is an equation, the values produced are booleans. Authors should set the value generators for variables to produce values that satisfy the equation about half of the time, but different forms of the correct expression can produce slightly different values due to floating point error, which would mean the equation is not satisfied.

I've come up with two solutions to this:

• when generating number values, convert them to decimal so the precision is fixed, hopefully avoiding rounding error.
• replace every equation sign in the expressions to be compared with the isclose function, allowing some tolerance for error.

I prefer the second option, since it matches what the marking algorithm does for non-equations.

[christianp]

Should also deal with comparisons.

[christianp]

The equality test for numbers already uses isclose, so I was a bit confused about how this bug could occur.

After lots of digging, this is the problem: when evaluating a=b, the logic eventually uses isclose, which allows both absolute and relative tolerances. When both sides are quite big, the relative tolerance is generous. If you rearrange the equation so that both sides are quite small, the relative tolerance is smaller, so the comparison fails.

I think this has to be a "be aware of" problem, rather than something we can avoid automatically.