Image comparison errors on Linux 32-bit

I'm testing 32-bit manylinux wheels for matplotlib 2.0.0b1. I'm building with export MPLLOCALFREETYPE=1. All the tests are passing on 64-bit:

https://s3.amazonaws.com/archive.travis-ci.org/jobs/138543116/log.txt

But - I'm getting lots of small RMS image differences when testing the 32-bit wheel:

https://s3.amazonaws.com/archive.travis-ci.org/jobs/138543118/log.txt

I guess this is due to small differences in freetype results on 32- and 64-bit? Can y'all suggest a good way to work round this?

Can you get access to any of the output?

I do not think we regularly test on 32bit linux, but we do test on 32bit windows which pass.

The easiest way to work around this would be to add a global flag to the tests to set the error 'floor'.

Hmm - looking at the log - it seems that there are some differences that are pretty large.

I tried doing a minimal install and test into another Docker container, so:

docker run -ti --rm -v $PWD:/io f69m/ubuntu32:14.04 /bin/bash

Then:

source /io/test_mpl_32.sh

Where test_mpl_32.sh is:

apt-get update
apt-get install -y pkg-config git libpng-dev libz-dev
apt-get install -y python3-dev python3-numpy python3-pip
git clone https://github.com/matplotlib/matplotlib.git
export MPLLOCALFREETYPE=1
cd matplotlib
pip3 install -e .
pip3 install nose mock
python3 tests.py -sv >& test.log

Log and images at : http://nipy.bic.berkeley.edu/scipy_installers/tmp/

Some of these failures look pretty cool:

Some of these looks like there are big solid regions where the difference in numerical errors between the 32bit and 64bit are flipping it from one bin to the next in the color mapping.

The worst tests are specgram:

test_axes/specgram_freqs_linear.png : 8.915
test_axes/specgram_freqs.png : 8.915
test_axes/specgram_magnitude_freqs_linear.png : 8.912
test_axes/specgram_magnitude_freqs.png : 8.912
test_axes/specgram_angle_freqs.png : 2.87

followed by two date/time things:

test_axes/date_timezone_x_and_y.png : 3.041
test_axes/single_date.png : 1.969

and the rest are less than 1.

I am not surprised about specgram failures, as that is highly sensitive to
numerical accuracy, and they were problematic ones when getting the 32-bit
Windows tests passing as well. So, I would be in favor of bumping the
tolerances for them.

The others... I don't know why they would be problematic.

On Tue, Jun 21, 2016 at 10:32 PM, Elliott Sales de Andrade <
notifications@github.com> wrote:

The worst tests are specgram:

test_axes/specgram_freqs_linear.png : 8.915

test_axes/specgram_freqs.png : 8.915

test_axes/specgram_magnitude_freqs_linear.png : 8.912

test_axes/specgram_magnitude_freqs.png : 8.912

test_axes/specgram_angle_freqs.png : 2.87 followed by two date/time
things:

test_axes/date_timezone_x_and_y.png : 3.041

test_axes/single_date.png : 1.969 and the rest are less than 1.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#6604 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AARy-JKI_o5xDaxH2AqUa-EfxUjypq9kks5qOJ6jgaJpZM4I45Xz
.

Many failures still for 2.0.0b4 build : https://s3.amazonaws.com/archive.travis-ci.org/jobs/158666401/log.txt

As part of building Fedora packages, I introduced some tolerance for 32-bit builds, e.g., #17800. Tests pass there, so I think there's no need to keep this open.

Navigation Menu

Repository navigation

Image comparison errors on Linux 32-bit #6604

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Image comparison errors on Linux 32-bit #6604

Description

Activity

tacaswell commented on Jun 20, 2016

matthew-brett commented on Jun 21, 2016

tacaswell commented on Jun 21, 2016

QuLogic commented on Jun 22, 2016

WeatherGod commented on Jun 22, 2016

matthew-brett commented on Sep 9, 2016

QuLogic commented on Jun 3, 2021

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions