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

test_colors.test_Normalize fails in 2.0.0b4 on Fedora rawhide/aarch64 (ARMv8) #7159

Closed
rathann opened this issue Sep 22, 2016 · 8 comments

Comments

Projects
None yet
5 participants
@rathann
Copy link

commented Sep 22, 2016

To help us understand and resolve your issue please check that you have provided
the information below.

  • Matplotlib version, Python version and Platform (Windows, OSX, Linux ...)

    2.0.0b4, python-2.7.12-6.fc26, python-3.5.2-4.fc26, Fedora rawhide/aarch64 (ARMv8)

  • How did you install Matplotlib and Python (pip, anaconda, from source ...)

    matplotlib from source, python from system packages

======================================================================
FAIL: matplotlib.tests.test_colors.test_Normalize
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest
    self.test(*self.arg)
  File "/builddir/build/BUILDROOT/python-matplotlib-2.0.0-0.1.b4.fc26.aarch64/usr/lib64/python2.7/site-packages/matplotlib/tests/test_colors.py", line 210, in test_Normalize
    assert_equal(norm(1 + 50 * eps), .5)
AssertionError: 0.50096339113680154143 != 0.5

@tacaswell tacaswell added this to the 2.0.1 (next bug fix release) milestone Sep 22, 2016

@tacaswell

This comment has been minimized.

Copy link
Member

commented Sep 22, 2016

attn @anntzer I think you wrote this test.

It looks like this is explicitly a test of longdouble

eps = np.finfo(np.longdouble).resolution
norm = plt.Normalize(1, 1 + 100 * eps)
assert_equal(norm(1 + 50 * eps), .5)

which I assume is supported differently on ARM than on x86_64.

My gut reaction is that we need some sort of conditional here to not bother testing longdouble/float128 in ARM, but I do not know enough about ARM to be sure.

@anntzer

This comment has been minimized.

Copy link
Contributor

commented Sep 22, 2016

@rathann what does np.finfo(np.longdouble) return for you?
@tacaswell see #6700 for the origin of the test, I think (not very strongly) that the fix belongs in 2.0.

@rathann

This comment has been minimized.

Copy link
Author

commented Sep 22, 2016

@anntzer here's what I got from a fellow Fedora developer:
finfo(resolution=1e-33, min=-1.18973149536e+4932, max=1.18973149536e+4932, dtype=float128)

@anntzer

This comment has been minimized.

Copy link
Contributor

commented Sep 22, 2016

Ugh, so at least this is not different from what I have here.
Similarly to #7158 I think a VM image would be the best way to investigate this.

Edit: see below.

@QuLogic

This comment has been minimized.

Copy link
Member

commented Sep 22, 2016

@anntzer It's really the same for you?

On x86_64, I get finfo(resolution=1e-18, min=-1.18973149536e+4932, max=1.18973149536e+4932, dtype=float128) which has a much bigger resolution value.

@anntzer

This comment has been minimized.

Copy link
Contributor

commented Sep 22, 2016

Oops, didn't pay attention to the resolution. I get the same thing as @QuLogic, so yes, my resolution us much lower.
Actually 1e-33 looks "real" float128 instead of the "extended precision" (80 bits) we have on x86_64 (=1e-18).

The test computes ((1+50*eps)-1) / ((1+100*eps)-1) where eps is the resolution given. I think it's fair to let it pass as long as the result is between 0.495 and 0.505 (off by 1%, which should correspond to the 100*eps). (The purpose of the test was mostly to make sure that the 100*eps doesn't get eaten away when eps is smaller than the resolution of float64.) Thoughts?

@Kojoley

This comment has been minimized.

Copy link
Member

commented Sep 22, 2016

Maybe just assert norm(1 + np.finfo(np.longdouble).eps) > 1 is enough?

@anntzer

This comment has been minimized.

Copy link
Contributor

commented Sep 30, 2016

Should be fixed by #7167, please request a reopen otherwise.

@anntzer anntzer closed this Sep 30, 2016

@QuLogic QuLogic modified the milestones: 2.0 (style change major release), 2.0.1 (next bug fix release) Dec 7, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.