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

[rathann]

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]

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]

@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]

@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]

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]

@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]

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]

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

[anntzer]

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