Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

In a42 the almost_equal test is probably wrong #99

Open
ikirill opened this issue Jan 2, 2018 · 1 comment
Open

In a42 the almost_equal test is probably wrong #99

ikirill opened this issue Jan 2, 2018 · 1 comment

Comments

@ikirill
Copy link
Contributor

ikirill commented Jan 2, 2018

I mean this test:

cc03ba6#diff-9471aab4b037f803f311ca8d2d35fe8fR558

It potentially uses the wrong type (Float64, which is not necessarily the type it's working with), and also it seems to use realmin in place of eps, where eps is the appropriate value.

I want to change it to

abs(x - y) < 32 * max(eps(x), eps(y))

which is probably what was intended anyway.

@ikirill
Copy link
Contributor Author

ikirill commented Jan 4, 2018

Okay, I now found it in the original paper, the condition there is specified as x-y == 0. The test abs(x-y) <= 32 * 1e-308 essentially accomplishes the same thing, because either x-y will be on the order of max(abs(x),abs(y))*eps(), or exactly zero, so I think this is identical, slightly roundabout way of checking x-y==0.

See http://www.netlib.org/toms-2014-06-10/748 at the lines starting with PROF=(FA-FB)...

Perhaps the reason for writing it this way was the infamous maxim "don't test floating point numbers for equality", so it was a way of "fixing" x==y?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant