Relative epsilon calculations with 0 and a very small number will fail

[thoni56]

Issue 2 in #135 reported by @KabooHahahein:

Eg. assert_that_double(0.000000000000001, is_equal_to_double(0));
Occurs because the implementation uses relative epsilons. The valid range for the above example is computed as [0.000000000000001001, 0.000000000000000999] if there are 4 significant figures. Thus, 0 should fail, but it is unintuitive.

[thoni56]

Wrong issue number in commit which fixed #146.

[thoni56]

@KabooHahahein could you explain this in more detail? Are you saying that the example should fail, but doesn't? And that fail is unintuitive, but correct?

Since I'm a fan of intuitive stuff, what other implications will keeping this "wrong" behaviour have?

Do you have a suggestion for a fix?

[thoni56]

@KabooHahahein Found this page, does that cover the issues you have reported?

[KabooHahahein]

It seems counter intuitive that 0.000000000000001 would fail an equals assertion with 0. If, for example, I use 3 significant figures, I would assume that the range for the assertion with 0 would be [-0.001, 0.001], but it turns out that this would fail the asssertion. This is a common issue with floating point numbers, as if you choose relative epsilons for comparisons, you end up with this situation where the actual positive range is based on your non-zero value. But it breaks down if your non-zero value is close enough to 0.

https://randomascii.wordpress.com/2012/02/25/comparing-floating-point-numbers-2012-edition/ describes this pretty well (see "Infernal zero" section). There is no all-in-one solution to this problem - it depends on what you're trying to do.

[thoni56]

Woah. Dude. Wonder if @d-meiser knew about this complexity, I sure didn't ;-)

So here we should probably just document how it works, right?

[d-meiser]

I had an idea that floating point comparisons are a bit of a problem especially near zero. But didn't know what the "rightest" solution was. gtest and the boost unit test library have check macros for floating point numbers. Might be worth having a look at what those libraries do. Even if there is no universally good solution it may be best to do what others do for the sake of consistency and to make the behavior less surprising to users.

[thoni56]

As shown in the discussion around the PR #151, with the current design, this is expected behaviour.

But this might be read as a feature request for absolute tolerance in addition to significant figures, so I've relabled it as an enhancement.