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

Activity

1. tacaswell

   added this to the 2.0.1 (next bug fix release)This milestone has been deleted milestone on Sep 22, 2016
2. tacaswell commented on Sep 22, 2016

   

   tacaswell

   on Sep 22, 2016

   Member

   More actions

   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.
3. anntzer commented on Sep 22, 2016

   

   anntzer

   on Sep 22, 2016

   Last edited by anntzer

   Contributor

   More actions

   @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.
4. rathann commented on Sep 22, 2016

   

   rathann

   on Sep 22, 2016

   Last edited by rathann

   Author

   More actions

   @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)
5. anntzer commented on Sep 22, 2016

   

   anntzer

   on Sep 22, 2016

   Last edited by anntzer

   Contributor

   More actions

   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.
6. QuLogic commented on Sep 22, 2016

   

   QuLogic

   on Sep 22, 2016

   Member

   More actions

   @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.
7. anntzer commented on Sep 22, 2016

   

   anntzer

   on Sep 22, 2016

   Last edited by anntzer

   Contributor

   More actions

   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?
8. Kojoley commented on Sep 22, 2016

   

   Kojoley

   on Sep 22, 2016

   Member

   More actions

   Maybe just assert norm(1 + np.finfo(np.longdouble).eps) > 1 is enough?
9. anntzer commented on Sep 30, 2016

   

   anntzer

   on Sep 30, 2016

   Contributor

   More actions

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

    closed this as completedon Sep 30, 2016
11. QuLogic

    modified the milestones: 2.0 (style change major release)This milestone has been deleted, 2.0.1 (next bug fix release)This milestone has been deleted on Dec 7, 2016