Skip to content

Loading…

FAIL: matplotlib.tests.test_transforms.test_pre_transform_plotting.test on Python 3.x #1120

Merged
merged 1 commit into from

4 participants

@mdboom
Matplotlib Developers member

This fails on Python 3.x only.

======================================================================
FAIL: matplotlib.tests.test_transforms.test_pre_transform_plotting.test
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/mdboom/python3/lib/python3.2/site-packages/nose/case.py", line 198, in runTest
    self.test(*self.arg)
  File "/home/mdboom/python3/lib/python3.2/site-packages/matplotlib/testing/decorators.py", line 39, in failer
    result = f(*args, **kwargs)
  File "/home/mdboom/python3/lib/python3.2/site-packages/matplotlib/testing/decorators.py", line 158, in do_test
    '(RMS %(rms).3f)'%err)
matplotlib.testing.noseclasses.ImageComparisonFailure: images not close: /home/mdboom/Work/tmp/matplotlib/tests3/result_images/test_transforms/pre_transform_data_svg.png vs. /home/mdboom/Work/tmp/mat
plotlib/tests3/result_images/test_transforms/pre_transform_data-expected_svg.png (RMS 720.791)
@pelson pelson was assigned
@mdboom
Matplotlib Developers member

Here's the failing SVG

https://gist.github.com/3438697

@pelson: Any idea what's going on here? Some sort of floating point thing? I wonder if it's related to a difference in the division operator under 2.x vs. 3.x (just a wild guess here).

@pelson
Matplotlib Developers member

Sounds plausible, but I don't specifically remember doing any actual math modifications to the code.

I'm going to have to get myself set up with a full python3 install. I will take a look at this, but unfortunately it won't be until Weds (the 29th).

Thanks for the gist btw.

@pelson
Matplotlib Developers member

Could be related to #1194.

@pelson
Matplotlib Developers member

Could be related to #1194.

Sadly not. The shift, as I think you already saw, is a pixel difference on the barbs. Yet to track it down...

@pelson
Matplotlib Developers member

Because the pdf and png versions are the same, I was hopeful that this would be a simple from __future__ import division in backend_svg.py. Unfortunately not.

@pelson
Matplotlib Developers member

The diffs of the raw svg file are:

--- python32.svg    2012-09-04 13:52:15.747076592 +0100
+++ python27.svg    2012-09-04 13:52:57.018998230 +0100
@@ -77,7 +77,7 @@
 L333.997 -59.1134" id="C1_0_8365cdde6d"/>
     </defs>
     <g clip-path="url(#p7ff5b81e1d)">
-     <use style="fill:#0040ff;" x="0" xlink:href="#C1_0_8365cdde6d" y="432.0"/>
+     <use style="fill:#0041ff;" x="0" xlink:href="#C1_0_8365cdde6d" y="432.0"/>
     </g>
    </g>
    <g id="PathCollection_3">
@@ -106,7 +106,7 @@
 L293.76 -86.5685" id="C2_0_ebb82fc4fe"/>
     </defs>
     <g clip-path="url(#p7ff5b81e1d)">
-     <use style="fill:#00c0ff;" x="0" xlink:href="#C2_0_ebb82fc4fe" y="432.0"/>
+     <use style="fill:#00c1ff;" x="0" xlink:href="#C2_0_ebb82fc4fe" y="432.0"/>
     </g>
    </g>
    <g id="PathCollection_4">
@@ -555,22 +555,22 @@
      <use style="fill:#0034ff;" x="0" xlink:href="#C8_6_a874fe0e1e" y="432.0"/>
     </g>
     <g clip-path="url(#p7ff5b81e1d)">
-     <use style="fill:#004cff;" x="0" xlink:href="#C8_7_35e396c57a" y="432.0"/>
+     <use style="fill:#004dff;" x="0" xlink:href="#C8_7_35e396c57a" y="432.0"/>
     </g>
     <g clip-path="url(#p7ff5b81e1d)">
-     <use style="fill:#0060ff;" x="0" xlink:href="#C8_8_feb37e9f02" y="432.0"/>
+     <use style="fill:#0061ff;" x="0" xlink:href="#C8_8_feb37e9f02" y="432.0"/>
     </g>
     <g clip-path="url(#p7ff5b81e1d)">
-     <use style="fill:#0078ff;" x="0" xlink:href="#C8_9_e50a7343f5" y="432.0"/>
+     <use style="fill:#0079ff;" x="0" xlink:href="#C8_9_e50a7343f5" y="432.0"/>
     </g>
     <g clip-path="url(#p7ff5b81e1d)">
-     <use style="fill:#0090ff;" x="0" xlink:href="#C8_a_3892a86142" y="432.0"/>
+     <use style="fill:#0091ff;" x="0" xlink:href="#C8_a_3892a86142" y="432.0"/>
     </g>
     <g clip-path="url(#p7ff5b81e1d)">
-     <use style="fill:#00a4ff;" x="0" xlink:href="#C8_b_5be8a13ffd" y="432.0"/>
+     <use style="fill:#00a5ff;" x="0" xlink:href="#C8_b_5be8a13ffd" y="432.0"/>
     </g>
... clipped lots of the same...
@@ -7602,12 +7602,12 @@
     <g id="ytick_2">
      <g id="line2d_15">
       <g>
-       <use style="stroke:#000000;stroke-linecap:butt;stroke-width:0.5;" x="72.0" xlink:href="#me8a85f7bf6" y="310.131977775"/>
+       <use style="stroke:#000000;stroke-linecap:butt;stroke-width:0.5;" x="72.0" xlink:href="#mc8fcea1516" y="310.131977775"/>
       </g>
      </g>
      <g id="line2d_16">
       <g>
-       <use style="stroke:#000000;stroke-linecap:butt;stroke-width:0.5;" x="518.4" xlink:href="#m1a32005dea" y="310.131977775"/>
+       <use style="stroke:#000000;stroke-linecap:butt;stroke-width:0.5;" x="518.4" xlink:href="#m0d5b0a6425" y="310.131977775"/>
       </g>
      </g>
      <g id="text_8">
@@ -7621,12 +7621,12 @@
     <g id="ytick_3">
      <g id="line2d_17">
       <g>
-       <use style="stroke:#000000;stroke-linecap:butt;stroke-width:0.5;" x="72.0" xlink:href="#me8a85f7bf6" y="247.377325925"/>
+       <use style="stroke:#000000;stroke-linecap:butt;stroke-width:0.5;" x="72.0" xlink:href="#mc8fcea1516" y="247.377325925"/>
       </g>
      </g>
      <g id="line2d_18">
       <g>
-       <use style="stroke:#000000;stroke-linecap:butt;stroke-width:0.5;" x="518.4" xlink:href="#m1a32005dea" y="247.377325925"/>
+       <use style="stroke:#000000;stroke-linecap:butt;stroke-width:0.5;" x="518.4" xlink:href="#m0d5b0a6425" y="247.377325925"/>
       </g>
      </g>
      <g id="text_9">
@@ -7640,12 +7640,12 @@
     <g id="ytick_4">
      <g id="line2d_19">
       <g>
-       <use style="stroke:#000000;stroke-linecap:butt;stroke-width:0.5;" x="72.0" xlink:href="#me8a85f7bf6" y="184.622674075"/>
+       <use style="stroke:#000000;stroke-linecap:butt;stroke-width:0.5;" x="72.0" xlink:href="#mc8fcea1516" y="184.622674075"/>
       </g>
      </g>
      <g id="line2d_20">
       <g>
-       <use style="stroke:#000000;stroke-linecap:butt;stroke-width:0.5;" x="518.4" xlink:href="#m1a32005dea" y="184.622674075"/>
+       <use style="stroke:#000000;stroke-linecap:butt;stroke-width:0.5;" x="518.4" xlink:href="#m0d5b0a6425" y="184.622674075"/>
       </g>
      </g>
      <g id="text_10">
@@ -7659,12 +7659,12 @@
     <g id="ytick_5">
      <g id="line2d_21">
       <g>
-       <use style="stroke:#000000;stroke-linecap:butt;stroke-width:0.5;" x="72.0" xlink:href="#me8a85f7bf6" y="121.868022225"/>
+       <use style="stroke:#000000;stroke-linecap:butt;stroke-width:0.5;" x="72.0" xlink:href="#mc8fcea1516" y="121.868022225"/>
       </g>
      </g>
      <g id="line2d_22">
       <g>
-       <use style="stroke:#000000;stroke-linecap:butt;stroke-width:0.5;" x="518.4" xlink:href="#m1a32005dea" y="121.868022225"/>
+       <use style="stroke:#000000;stroke-linecap:butt;stroke-width:0.5;" x="518.4" xlink:href="#m0d5b0a6425" y="121.868022225"/>
       </g>
      </g>
      <g id="text_11">
@@ -7678,12 +7678,12 @@
     <g id="ytick_6">
      <g id="line2d_23">
       <g>
-       <use style="stroke:#000000;stroke-linecap:butt;stroke-width:0.5;" x="72.0" xlink:href="#me8a85f7bf6" y="59.1133703747"/>
+       <use style="stroke:#000000;stroke-linecap:butt;stroke-width:0.5;" x="72.0" xlink:href="#mc8fcea1516" y="59.1133703747"/>
       </g>
      </g>
      <g id="line2d_24">
       <g>
-       <use style="stroke:#000000;stroke-linecap:butt;stroke-width:0.5;" x="518.4" xlink:href="#m1a32005dea" y="59.1133703747"/>
+       <use style="stroke:#000000;stroke-linecap:butt;stroke-width:0.5;" x="518.4" xlink:href="#m0d5b0a6425" y="59.1133703747"/>
       </g>
      </g>
      <g id="text_12">
@pelson
Matplotlib Developers member

Those SVGs convert to identical pngs with inkscape -z in.svg --export-png out.png, hence, I can only conclude that it is the conversion process in mpl (which is using inkscape) which is python version dependent.

@mdboom
Matplotlib Developers member

Hmm... The PNGs are not identical. The baseline, the output from matplotlib master under python 2 and python 3 are all different in the barbs for me. I'll look into this further.

@mdboom
Matplotlib Developers member

I'm surprised at your diff between the 2.7 and 3.2 output. My installation gives differences in the actual path data, eg.:

@@ -1440,1653 +1440,1653 @@
     <defs>
      <path d="
 M0 0
-L-24.4876 0.778189
-L-19.8962 0.632278
-L-21.5823 -4.21661
-L-19.8962 0.632278
+L-24.2365 0.770207
+L-19.6921 0.625793
+L-21.361 -4.17336
+L-19.6921 0.625793
 z
-" id="Cb_0_bc8a274eed"/>
+" id="Cb_0_c4b9db3e0e"/>
      <path d="
 M0 0
-L-24.4934 0.568021
-L-19.9009 0.461517
-L-21.5453 -4.40166
-L-19.9009 0.461517
+L-24.2422 0.562195
+L-19.6968 0.456784
+L-21.3244 -4.35652
+L-19.6968 0.456784
 z
-" id="Cb_1_625cafbf77"/>
+" id="Cb_1_0135c2e85d"/>
      <path d="
 M0 0
-L-24.4993 0.188265
-L-19.9057 0.152966
-L-21.4745 -4.73512
-L-19.9057 0.152966
-z
-" id="Cb_2_1963d3a56a"/>
-     <path d="
-M2.25029e-16 -3.675
-L-1.13564 -3.49513
-L-2.16011 -2.97314
-L-2.97314 -2.16011
-L-3.49513 -1.13564
-L-3.675 -4.50058e-16
-L-3.49513 1.13564
-L-2.97314 2.16011
-L-2.16011 2.97314
-L-1.13564 3.49513
-L-6.75087e-16 3.675
-L1.13564 3.49513
-L2.16011 2.97314
-L2.97314 2.16011
-L3.49513 1.13564
-L3.675 9.00115e-16
-L3.49513 -1.13564
-L2.97314 -2.16011
-L2.16011 -2.97314
-L1.13564 -3.49513
-L2.25029e-16 -3.675
-L2.25029e-16 -3.675
-L1.13564 -3.49513
-L2.16011 -2.97314
-L2.97314 -2.16011
-L3.49513 -1.13564
-L3.675 9.00115e-16
-L3.49513 1.13564
-L2.97314 2.16011
-L2.16011 2.97314
-L1.13564 3.49513
-L-6.75087e-16 3.675
-L-1.13564 3.49513
-L-2.16011 2.97314
-L-2.97314 2.16011
-L-3.49513 1.13564
-L-3.675 -4.50058e-16
-L-3.49513 -1.13564
-L-2.97314 -2.16011
-L-2.16011 -2.97314
-L-1.13564 -3.49513
-L2.25029e-16 -3.675
-z
-" id="Cb_3_91dfad6065"/>
-     <path d="
-M2.25029e-16 -3.675
-L-1.13564 -3.49513
-L-2.16011 -2.97314
-L-2.97314 -2.16011
-L-3.49513 -1.13564
-L-3.675 -4.50058e-16
-L-3.49513 1.13564
-L-2.97314 2.16011
-L-2.16011 2.97314
-L-1.13564 3.49513
-L-6.75087e-16 3.675
-L1.13564 3.49513
-L2.16011 2.97314
-L2.97314 2.16011
-L3.49513 1.13564
-L3.675 9.00115e-16
-L3.49513 -1.13564
-L2.97314 -2.16011
-L2.16011 -2.97314
-L1.13564 -3.49513
-L2.25029e-16 -3.675
-L2.25029e-16 -3.675
-L1.13564 -3.49513
-L2.16011 -2.97314
-L2.97314 -2.16011
-L3.49513 -1.13564
-L3.675 9.00115e-16
-L3.49513 1.13564
-L2.97314 2.16011
-L2.16011 2.97314
-L1.13564 3.49513
-L-6.75087e-16 3.675
-L-1.13564 3.49513
-L-2.16011 2.97314
-L-2.97314 2.16011
-L-3.49513 1.13564
-L-3.675 -4.50058e-16
-L-3.49513 -1.13564
-L-2.97314 -2.16011
-L-2.16011 -2.97314
-L-1.13564 -3.49513
-L2.25029e-16 -3.675
-z

etc.

@mdboom
Matplotlib Developers member

Note that there is a similar difference in the PDFs, it just has less of an influence on the output.

@mdboom mdboom Closes issue #1120. There were two problems: barbs were being printed…
… slightly differently on Python 3 due to the difference of old vs. division. Colors were being converted to hex slightly wrong on Python 2 -- the use of np.round rather than Python's builtin round provides consistent behavior.
11ffa8a
@mdboom
Matplotlib Developers member

I've attached a PR that seems to resolve this.

@efiring efiring commented on the diff
lib/matplotlib/colors.py
@@ -219,7 +219,7 @@ def is_color_like(c):
def rgb2hex(rgb):
'Given an rgb or rgba sequence of 0-1 floats, return the hex string'
- return '#%02x%02x%02x' % tuple([round(val*255) for val in rgb[:3]])
+ return '#%02x%02x%02x' % tuple([np.round(val*255) for val in rgb[:3]])
@efiring Matplotlib Developers member
efiring added a note

Micro-optimization: the part on the right is a bit quicker and perhaps more readable as
tuple(np.round(np.asarray(rgb[:3]) * 255)).

Or tuple((np.asarray(rgb[:3]) * 255).round()), which is slightly more efficient. Not that efficiency matters at this microsecond level.

@WeatherGod Matplotlib Developers member

watch out when doing asarray(). We support masked arrays, so it really should be asanyarray(). Although, admittedly, in this context, it probably makes no difference.

@efiring Matplotlib Developers member
efiring added a note

Agreed, but I don't think either version would work sensibly with rgb as a masked array. And the docstring says "floats", with no mention of masked array support.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
@pelson
Matplotlib Developers member

Thanks Mike. I have literally imported future division in all mpl .py files and it appeared to have no effect. I think I need to go away and look at my setup to make sure I'm not overlooking something.

The PR looks good. +1 from me.

@mdboom mdboom merged commit b5eb1d0 into matplotlib:master
@mdboom mdboom deleted the mdboom:issue1120 branch
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Commits on Sep 4, 2012
  1. @mdboom

    Closes issue #1120. There were two problems: barbs were being printed…

    mdboom committed
    … slightly differently on Python 3 due to the difference of old vs. division. Colors were being converted to hex slightly wrong on Python 2 -- the use of np.round rather than Python's builtin round provides consistent behavior.
Something went wrong with that request. Please try again.