Skip to content

test_slider_horizontal_vertical fails on 32-bit GNU/Linux #16783

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

Closed
mbakke opened this issue Mar 16, 2020 · 7 comments
Closed

test_slider_horizontal_vertical fails on 32-bit GNU/Linux #16783

mbakke opened this issue Mar 16, 2020 · 7 comments

Comments

@mbakke
Copy link

mbakke commented Mar 16, 2020

Bug report

Hello,

Running the matplotlib test suite fails on i686 systems.

To reproduce, run

python tests.py -v -m "not network and not webagg"

...on a 32-bit GNU/Linux system.

Actual outcome

=================================== FAILURES ===================================                   
_______________________ test_slider_horizontal_vertical ________________________

    def test_slider_horizontal_vertical():
        fig, ax = plt.subplots()
        slider = widgets.Slider(ax=ax, label='', valmin=0, valmax=24,
                                valinit=12, orientation='horizontal')
        slider.set_val(10)
        assert slider.val == 10
        # check the dimension of the slider patch in axes units
        box = slider.poly.get_extents().transformed(ax.transAxes.inverted())
>       assert_allclose(box.bounds, [0, 0, 10/24, 1])
E       AssertionError:
E       Not equal to tolerance rtol=1e-07, atol=0
E
E       Mismatch: 25%
E       Max absolute difference: 1.11022302e-16
E       Max relative difference: 2.66453526e-16
E        x: array([ 0.000000e+00, -2.310706e-18,  4.166667e-01,  1.000000e+00])
E        y: array([0.      , 0.      , 0.416667, 1.      ])

/gnu/store/8g8yfikj63wf0y3hwvpk00hqj5wpfs7v-python-matplotlib-3.1.2/lib/python3.7/site-packages/matplotlib/tests/test_widgets.py:333: AssertionError

Expected outcome

All tests pass.

Matplotlib version

  • Operating system: GNU/Linux
  • Matplotlib version: 3.1.2
  • Matplotlib backend (print(matplotlib.get_backend())):
  • Python version: 3.7.4
  • Jupyter version (if applicable):
  • Other libraries:
@QuLogic
Copy link
Member

QuLogic commented Mar 16, 2020

Strange, Fedora runs build on 32-bit systems and needs no patch for this result.

Operating system: GNU/Linux

That is a bit vague. Are you running with unusual libc or optimizations?

@Apteryks
Copy link

Hello,

I can reproduce the issue. I'm also using GNU Guix. Attached is a full log of the build. The versions used can be seed by inspecting the entries in the LIBRARY_PATH environment variable set amongst others near the beginning of the log. Here's LIBRARY_PATH entries broken on separate lines for readability:

/gnu/store/cqd9maq21qnwrvq87xyba2a9yzih9scr-python-pytest-5.3.5/lib
/gnu/store/rfmk0hvhnl7i12k3xvwxwvypswxdk9w8-python-mock-3.0.5/lib
/gnu/store/nsx125rx3ggdkrfnch5wnny5fwa5xrmr-libpng-1.6.37/lib
/gnu/store/fga683r4ibvir6baxq1k1c39c3n9vksg-freetype-2.10.1/lib
/gnu/store/ifid398z68c3lr782mg8qpp2smc1djlv-cairo-1.16.0/lib
/gnu/store/555921cimgx7dnmyrr2q4m36ccszp5nw-glib-2.62.6/lib
/gnu/store/xxwm0gnajpzm2jcb84ldj4zmdz4c6j51-tcl-8.6.10/lib
/gnu/store/b5rglm6r3853h3x90vwn6d644i9ykxsm-tk-8.6.10/lib
/gnu/store/4y9shbhbgv7ahv04b4hc8zmvyh88l358-python-cycler-0.10.0/lib
/gnu/store/2xrvcklrnphg6kzpc7famvpap50jwm5i-python-kiwisolver-1.0.1/lib
/gnu/store/9xlhapzk0dw38pign2njxaby8a857pr7-python-pyparsing-2.4.6/lib
/gnu/store/l0w55ha8b25wmdn9sga4indjvr01aw0x-python-pygobject-3.34.0/lib
/gnu/store/nfs4hkxjvq7r2i359960nhqa87hs44py-gobject-introspection-1.62.0/lib
/gnu/store/pycr25brp0wsdrw5n5c8idhix5pkmsb4-python-3.8.2-tk/lib
/gnu/store/i8rarshij0qcfh99j9y3asqwghmgb1bd-python-dateutil-2.8.1/lib
/gnu/store/53pc0vvpy0dak8wla7qnj6vg1f0ka2v5-python-numpy-1.17.3/lib
/gnu/store/a25kv2v1yq8rjirk3yjbslahsnsr8c0i-python-pillow-6.2.1/lib
/gnu/store/fl3f1m9xz07840xa7xcr8py5hrff7blq-python-pytz-2019.1/lib
/gnu/store/59alkwvkkzb82xzvchzj0lb72fb1mbmq-python-six-1.14.0/lib
/gnu/store/w5b3ynrkjzmqm09yahfl7iz6z1qqakdz-python-pycairo-1.19.1/lib
/gnu/store/2vrj842z1h407gs6m2vgykg58bfqxv6m-python-cairocffi-0.9.0/lib
/gnu/store/n1jk0w2wa4vpwmixaqn2y3la1l2sizzi-bzip2-1.0.8/lib
/gnu/store/7p36raqgk6vn47bflxc9bsclqiib3phi-xz-5.2.4/lib
/gnu/store/lpkf3ydcdvxn8gcrzaq9cp3ri05h8qhs-file-5.38/lib
/gnu/store/9iwlsj7d6ffqhshy8qshf7p4fqwfwrvn-gawk-5.0.1/lib
/gnu/store/50lyzn9bz6x4da66648kry29wn8afird-binutils-2.34/lib
/gnu/store/z4li262il798hbl0l1h1k3a5g7r6bffa-glibc-2.31/lib
/gnu/store/rzk3v28mhi4m7sh0qippp9a5rzy03rkg-glibc-2.31-static/lib
/gnu/store/x6i3vfg4gaqd42cqb6mzk52v4lds1467-glibc-utf8-locales-2.31/lib
/gnu/store/9mqdx9h1pxpmdsy71r9r99zl23ismsfi-python-3.8.2/lib
/gnu/store/i189lsqlbg71iy3w593720nfczmn9whg-python-wcwidth-0.1.8/lib
/gnu/store/ldvl5b271j3mhs1a28y8560m5c6nr2y0-python-six-bootstrap-1.14.0/lib
/gnu/store/di2bz1xf0p14blkb54hrw3yvq58m5wmp-python-py-1.8.1/lib
/gnu/store/gq8fidp9vq02s1gj7f1gxjxwl9l1jgpi-python-pluggy-0.13.1/lib
/gnu/store/i760j5b7zffqbjc2pg1a2q9i049ajlm5-python-packaging-bootstrap-20.0/lib
/gnu/store/8mjxs0dxgrbfhzhr0wpgqbpqia4yn980-python-more-itertools-8.2.0/lib
/gnu/store/qsd9jvmqmhxsmklnzw8wf6nnhr2dycby-python-attrs-bootstrap-19.3.0/lib
/gnu/store/is0pb848mvg44zvm9107haav1j1qzndz-python-atomicwrites-1.3.0/lib
/gnu/store/pqyqxd5mbvlb22ifxzp4q2skjfq1p8yj-zlib-1.2.11/lib
/gnu/store/b2mp3sqajjxp1qgvk17as635g9hj8adi-pixman-0.38.4/lib
/gnu/store/3zdw6innfla52jaylz8y6vvswvxn56xc-libxrender-0.9.10/lib
/gnu/store/9x558k5m9x4b9yn082y1hz18pnpw8r4n-libxext-1.3.4/lib
/gnu/store/yp9gdl9dla4d4iallw36lp9jih8pnkdq-libx11-1.6.9/lib
/gnu/store/0b5dm5j6i1495dpc5gqvm3haxjqw9ggh-fontconfig-2.13.1/lib
/gnu/store/dlrp9g7plpl4py17wgd1qp9m3c8sls3l-libselinux-3.0/lib
/gnu/store/5ffrqmfh2c0dgmh9ji3lgvnvgsnmlhfp-util-linux-2.35.1-lib/lib
/gnu/store/pn4bci1x4dsmaafmslx6g61af7n2j0sy-libffi-3.3/lib
/gnu/store/kiz15vy5mv2jw37365j76cy1a88a3p2a-pcre-8.44/lib
/gnu/store/narrfv3r0xm207d4mxnss3vj04qk0gzg-python-olefile-0.46/lib
/gnu/store/fwrdc8qv4gq1896mazazqhnxyq8rrvqc-python-xcffib-0.6.0/lib
/gnu/store/mwyvi77wn6ixykscbxrnijfb11qr6ksr-libxcb-1.14/lib
/gnu/store/kwdpvjv4bf2vhc39rs9yqmdms9z3ylpm-expat-2.2.9/lib
/gnu/store/3x44yvsap0ss63j8d7yv6wm63ngr3j12-libsepol-3.0/lib
/gnu/store/c0d2ppsdq6nji7y3d7fxicw9azc8xlw3-python-cffi-1.14.0/lib
/gnu/store/m5amycba5r76y12rglrzp76nzq1azagk-util-macros-1.19.2/lib
/gnu/store/y2yqlqxmvhm7dyaislz4v4gxj6d1407n-libxdmcp-1.1.3/lib
/gnu/store/b1gvxvp768cg86azj21izpb60s0z0d2n-libxau-1.0.9/lib
/gnu/store/yl23n24xrgv9w7y0y6p0gz1z1gqpgfv1-libpthread-stubs-0.4/lib
/gnu/store/pwfbx9idw0dampa5ww1f5czm6c0pvrh5-python-pycparser-2.20/lib

It's not using anything very particular; the glibc is at version 2.31 and GCC is version 7.5.0; Python is at 3.8.2.

Thanks!

27rvsrdwigczxd94w3dglqlwyf3a30-python-matplotlib-3.1.2-i686.drv.gz

@Apteryks
Copy link

Apteryks commented Nov 14, 2020

I've just gone through the thread of the original issue at https://issues.guix.gnu.org/40406, and someone came up with a patch that worked around the problem in this message: https://issues.guix.gnu.org/40406#4; it boils down to setting the -ffloat-store CFLAGS when the host architecture detected is i686. The GCC manual says this about such option:

'-ffloat-store'
     Do not store floating-point variables in registers, and inhibit
     other options that might change whether a floating-point value is
     taken from a register or memory.

     This option prevents undesirable excess precision on machines such
     as the 68000 where the floating registers (of the 68881) keep more
     precision than a 'double' is supposed to have.  Similarly for the
     x86 architecture.  For most programs, the excess precision does
     only good, but a few programs rely on the precise definition of
     IEEE floating point.  Use '-ffloat-store' for such programs, after
     modifying them to store all pertinent intermediate computations
     into variables.

I've tested it and it least allows the test suite to pass on i686-linux.

@tacaswell
Copy link
Member

I am 👍 on a patch the adding a tolerance to the failing assert_allclose(box.bounds, [0, 0, 10/24, 1]) (and a note about why it is there). I do not think we are actually worried about float precision here.

I suspect we could also ask the poly for its size in data space directly rather than getting its size in screen space and then converting back to data space.

@github-actions
Copy link

This issue has been marked "inactive" because it has been 365 days since the last comment. If this issue is still present in recent Matplotlib releases, or the feature request is still wanted, please leave a comment and this label will be removed. If there are no updates in another 30 days, this issue will be automatically closed, but you are free to re-open or create a new issue if needed. We value issue reports, and this procedure is meant to help us resurface and prioritize issues that have not been addressed yet, not make them disappear. Thanks for your help!

@github-actions github-actions bot added the status: inactive Marked by the “Stale” Github Action label Jul 12, 2023
@Apteryks
Copy link

Probably still relevant if the same test still exists.

@github-actions github-actions bot removed the status: inactive Marked by the “Stale” Github Action label Jul 17, 2023
@ksunden
Copy link
Member

ksunden commented Jul 19, 2023

We no longer support 32 bit builds (#25475 and #26125), therefore, closing

@ksunden ksunden closed this as completed Jul 19, 2023
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

5 participants