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

32bit rounding still failing #145

Open
matt-chan opened this issue Jul 12, 2016 · 7 comments
Open

32bit rounding still failing #145

matt-chan opened this issue Jul 12, 2016 · 7 comments
Assignees
Labels

Comments

@matt-chan
Copy link
Member

matt-chan commented Jul 12, 2016

So we're still getting issues with numerical instability when we go to 32bit rounding behaviour.

For example, these builds fail:
https://copr.fedorainfracloud.org/coprs/talcite/Horton-2.0.0/build/380108/

Did we ever merge in our FPU fix @tovrstra ?

@tovrstra
Copy link
Member

We kicked out of again for some reason. Don't remember why.

@matt-chan
Copy link
Member Author

Was it too ugly? I remember that it had to be called before we started anything. Maybe the more permanent fix is to just loosen the tolerances on the failing tests and just accept the fact that i686 and x86_64 rounding will be different...

Another option is to import fpufix.h (I'm pretty sure that's what it was called) on the cpp files that do math. I think numpy has consistent rounding behaviour on 32 and 64bit. We don't actually have that many cpp files.

As it stands though, it's a bit of a problem for fedora packaging, since i686 will be supported for a while longer, even if they don't classify it as primary architecture anymore.

@tovrstra
Copy link
Member

I vaguely remember that fpufix just broke other tests. (I'll try to look it up again.)

I'm a bit surprised that it is still a problem. I ran all unit tests of the 2.0.1 release on a fedora 23 32-bit virtual machine without any problems.

I tried the link above but I can't find a list of tests that are failing. Can you give me a direct link to the output that shows which unit tests break?

@tovrstra
Copy link
Member

tovrstra commented Jul 14, 2016

It was once in the code and I found the reason for removing it again: it broke tests on Debian 32 bit.

Also, fpufix cannot be applied locally to just some files. It applies to the entire process. If you want to use it, it should be called as early as possible to avoid inconsistencies.

Can you give instructions for reproducing the problem locally, e.g. in a virtual machine?

@matt-chan
Copy link
Member Author

Yes, a 32bit virtual machine should do it. I think that's how we tested it
last time.

Matt

On Thu, 14 Jul 2016 at 23:16 Toon Verstraelen notifications@github.com
wrote:

I found the reason for it: it broke tests on Debian 32 bit.

Also, fpufix cannot be applied locally to just some files. It applies to
the entire process. If you want to use it, it should be called as early as
possible to avoid inconsistencies.

Can you give instructions for reproducing the problem locally, e.g. in a
virtual machine?


You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#145 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AA_-NSVTuA00Y9eu9VSODWDMo4oduw2eks5qVqcKgaJpZM4JKYSn
.

@tovrstra tovrstra modified the milestone: 2.1.0 Sep 13, 2016
@tovrstra
Copy link
Member

These tests fail on Fedora 24 32 bit:

======================================================================
FAIL: horton.gbasis.test.test_boys.test_boys_array
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest
    self.test(*self.arg)
  File "/home/toon/.local/lib/python2.7/site-packages/horton/gbasis/test/test_boys.py", line 526, in test_boys_array
    assert output[m] == boys_function(m, t)
AssertionError

======================================================================
FAIL: horton.gbasis.test.test_ints.test_ralpha_repulsion_4_3_2_1
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest
    self.test(*self.arg)
  File "/home/toon/.local/lib/python2.7/site-packages/horton/gbasis/test/test_ints.py", line 2823, in test_ralpha_repulsion_4_3_2_1
    result0, -1.0)
  File "/home/toon/.local/lib/python2.7/site-packages/horton/gbasis/test/test_ints.py", line 2497, in check_ralpha_repulsion
    assert abs(result1 - result0).max() < 3e-7
AssertionError

@tovrstra
Copy link
Member

The Boys function (first failing test above) is compared to full precision, which should not be done. It may fail on some machines because the two implementations that are compared, have different orders of operations. Differences in rounding will indeed give different results.

@tovrstra tovrstra self-assigned this Jun 27, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants