Strange behaviour with some floating point subtraction

[shennan]

Why do these evaluations not equate to true?

They do equate correctly when not using a conditional (== answer), which makes me think that any funky floating/rounding logic is not being applied when evaluating conditions. For example:

[josdejong]

Welcome to the wonder world of floating point numbers... Basically, if you evaluate 8.3 - 8.2 in a JavaScript console, you will see the result is not 0.1 but 0.10000000000000142. So a simple equality check would fail.

The relational functions of math.js has some provisions for this problem, from the docs on equal:

The function tests whether the relative difference between x and y is smaller than the configured epsilon.

The default value of epsilon is 1e-14. I'm a bit amazed by size of the the round-off errors in the examples you gave. Maybe 1e-14 is a bit too small and we should change it to 1e-12 by default. Anyway, you can change it yourself, like:

math.config({epsilon: 1e-12});

math.eval('8.3 - 8.2 == 0.1'); // true

Alternatively, you can use Fractions or BigNumbers to prevent these round-off errors from occurring.

[shennan]

Would it not make sense to have conditional logic evaluate the expressions in the same way as they are evaluated elsewhere?

If this (without changing epsilon) is ok:

8.3 - 8.2; \\ 0.1

Then, by design, this should be ok:

8.3 - 8.2 == 0.1 ; \\ true

For that reason I see this as a bug. But open to debate. :-)

[shennan]

Ah, I've just realised. The actual library does not return the result 0.1 for the equation 8.3 - 8.2. Which means you must be doctoring the numbers in the demo page before they are fed back to the user.

Don't blame you for doing so, but it is confusing when you're testing your logic.

Is this the case?

[josdejong]

Yes floating points are confusing. No matter what we do, when using floating point numbers people will one day have this huge WTF that you experiencing right now (just do a simple search for "round-off" related issues).

The demo on the website simply rounds output to 14 significant digits, see docs here: http://mathjs.org/docs/datatypes/numbers.html#roundoff-errors

I've now changed the demo on the website to show the unformatted floating point result when hovering a result, maybe that helps a bit in reducing the confusion. What do you think?

[shennan]

I understand computational floating point issues. The 'WTF' was a result of your demo rounding the output. I assumed that your library was rounding, and therefore that your conditional logic should do the same. But the demo is rounding, masking the true behaviour of the library.

I do think you should avoid rounding on the demo, so as to avoid confusion for others that may be expecting actual output from the library. But that's just my opinion.

[josdejong]

Thanks for sharing your opinion. It's just that I expect that by outputting results with round-off errors will cause way more confusion than without (and people simply abandoning the library because it is "broken" at first sight).

From a more practical point of view, as an end user I think you normally want to see the results without round-off errors, else it's hard to read.

[shennan]

Fair enough. I agree that the end user would generally want to see output without round-off errors. Though, remember, this is not the default behaviour of the library; so they must first adjust config to do so. Changing this behaviour, however, could be seen as a breaking change.

But I do appreciate your opinion so I won't labour the point any more.

It is a very useful library, thank you.

[josdejong]

I was thinking about configuring the demo to use BigNumbers, that would resolve most round-off errors and would prevent these issues with equality checks :D.

[infusion]

Wouldn't it be a good idea to use rational numbers as long as possible? I mean most people enter rational numbers in there, and as long as they don't use rational exponents or logarithms, numbers will remain rational.

[josdejong]

I think it's best to just output decimals, that's most basic. The calculator on the website is just meant as a simple demo, It could be useful to expand it such that you can play around with different configuration options (Fraction, BigNumber, number) so you can immediately see what it does.

[josdejong]

I was thinking about how to point people in the right direction regarding round-off errors. The demo now displays an information icon when it has a result with round-off errors.

@shennan can you have a look at the demo and let me know what you think?

[shennan]

I think the explanation you've added is definitely a step in the right direction. Currently the 'more...' button links to localhost, though.

What do you think of something like this:

Although it doesn't look as minimal, it might prompt the user to click on it more.

[josdejong]

Oops, I fixed the link, thanks.

Yeah there is a sweet spot somewhere between giving no information at all and overflowing the user with it. Your idea looks neat, I adjusted the demo to show the text "round-off error". Let's see how this works out and if it helps people or scares them away ;).