-
-
Notifications
You must be signed in to change notification settings - Fork 7.9k
FAIL: matplotlib.tests.test_transforms.test_pre_transform_plotting.test on Python 3.x #1120
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
Conversation
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). |
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. |
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... |
Because the pdf and png versions are the same, I was hopeful that this would be a simple |
The diffs of the raw svg file are:
|
Those SVGs convert to identical pngs with |
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. |
I'm surprised at your diff between the 2.7 and 3.2 output. My installation gives differences in the actual path data, eg.:
etc. |
Note that there is a similar difference in the PDFs, it just has less of an influence on the output. |
…ng 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.
I've attached a PR that seems to resolve this. |
@@ -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]]) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Thanks Mike. I have literally imported future division in all mpl The PR looks good. +1 from me. |
FAIL: matplotlib.tests.test_transforms.test_pre_transform_plotting.test on Python 3.x
This fails on Python 3.x only.