FazBrowse GitHub Viewer | Trending |
URL:
| Home
Tools: [Download Repo ZIP]   [Original HTTPS Page]

Correct theta values when drawing a non-circular arc by dstansby · Pull Request #8047 · matplotlib/matplotlib · GitHub

Repository navigation

Correct theta values when drawing a non-circular arc - #8047

Merged
NelleV merged 2 commits into
matplotlib:masterfrom
dstansby:arc-theta
Mar 10, 2017
Merged

NelleV merged 2 commits into
matplotlib:masterfrom
dstansby:arc-theta

Conversation

dstansby commented Feb 8, 2017 •
edited
Loading

Copy link
Copy Markdown
Member

Fixes #8046. I'm not sure if this is the right place to do the correction, so a second opinion would be good. I've checked this works with a full range of angles.

tacaswell added this to the 2.1 (next point release) milestone Feb 8, 2017
Comment thread lib/matplotlib/tests/test_axes.py Outdated
ax.plot([1, 2, 3])


@image_comparison(baseline_images=['arc_angles'])

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

add remove_text=True and style='default' to the decorator to get the new defaults + drop all of the text (which makes the test more stable).

Copy link
Copy Markdown
Member

This will need an entry in whats new or api changes. The paranoid case here is that users have worked around this bug and we are now silently changing things under them so it needs to be documented.

Copy link
Copy Markdown
Member

This looks like the correct place to do this to me. Ellipse is implemented by holding transforms to re-scale a circular path so pushing this down into Path.arc is not right and Ellipse is for full coverage so pushing this into the base-class is not right either.

dstansby changed the title Correct theta values when drawing a non-circular ellipse Correct theta values when drawing a non-circular arc Feb 9, 2017

Copy link
Copy Markdown
Member Author

Does anyone know why the documentation build is failing with:

/Users/dstansby/matplotlib/doc/examples/units/ellipse_with_units.rst:8: WARNING: Exception occurred in plotting ellipse_with_units
 from /Users/dstansby/matplotlib/doc/mpl_examples/units/ellipse_with_units.py:
Traceback (most recent call last):
  File "/Users/dstansby/matplotlib/lib/matplotlib/sphinxext/plot_directive.py", line 525, in run_code
    six.exec_(code, ns)
  File "<string>", line 55, in <module>
  File "/Users/dstansby/matplotlib/lib/matplotlib/patches.py", line 1565, in __init__
    theta1 = theta_stretch(theta1, width / height)
TypeError: unsupported operand type(s) for /: 'TaggedValue' and 'TaggedValue'

Copy link
Copy Markdown
Contributor

As far as I understand, it seems like “width” and “height” are cm instances from this script and that the class used under the hood (TaggedValue) does not implement the division operation.

dstansby commented Feb 10, 2017 •
edited
Loading

Copy link
Copy Markdown
Member Author

Would anyone object to me just getting rid of http://matplotlib.org/examples/units/ellipse_with_units.html ? It doesn't seem to be showing any unique capabilities of units, and the 'comparison' just looks the same to me.

(and does it matter if my new code breaks drawing an ellipse with units?)

Copy link
Copy Markdown
Member

Yes and yes (although, it seems like the problem here is the exact unit implementation, not generally).

The unit support is an under-understood, but critical feature of mpl (JPL relies on it).

dstansby commented Feb 10, 2017 •
edited
Loading

Copy link
Copy Markdown
Member Author

As far as I can tell:

  • The correct way to convert from units to a number is call self.convert_xunits(width)
  • However this is just returning width unchanged as units
  • This is because there is no axis when __init__ is called on Arc, so the units are returned unchanged

so all this means there's no way of converting units within the __init__ bit of Arc, so the conversion and angle correction needs to happen somewhere else.

Copy link
Copy Markdown
Member Author

That should fix it, I've moved the new calculation into the draw() method.

QuLogic left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

LGTM mostly. Just a small tweak to the test.

Comment thread lib/matplotlib/tests/test_axes.py Outdated
theta2 = i * 360 / 9
theta1 = theta2 - 45
ax.add_patch(patches.Arc(centre, w, h, theta1=theta1, theta2=theta2))
# Straight line should intersect end of arc

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

Could you also add the start of the arc as well? Start -> origin -> end should work.

Comment thread lib/matplotlib/tests/test_axes.py Outdated
centre = (0.2, 0.5)

fig, axs = plt.subplots(3, 3)
for i, ax in enumerate(np.ravel(axs)):

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

enumerate(axs.flat)

for i, ax in enumerate(np.ravel(axs)):
theta2 = i * 360 / 9
theta1 = theta2 - 45
ax.add_patch(patches.Arc(centre, w, h, theta1=theta1, theta2=theta2))

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

Can you also add a full Ellipse patch with the same parameters but maybe half linewidth or alpha just to show that the arc is in a consistent place?

Copy link
Copy Markdown
Member Author

Thanks for the extra ideas for the test @QuLogic - once this has been reviewed I can squash everything down to a single commit.

QuLogic commented Feb 28, 2017

Copy link
Copy Markdown
Member

Is there anything backend-specific here? Do we need the SVG/PDF files?

Copy link
Copy Markdown
Member Author

Oh yes, I forgot that those were optional. I don't think there's anything backend specific, shall I just have a .png image test?

QuLogic commented Mar 2, 2017

Copy link
Copy Markdown
Member

Yes, I think we can drop the other ones and you can squash this.

Make arcs work with units

Add api change not for elliptical notes

Add background ellipse and extra line to test

Remove pdf and svg tests for arc angles

dstansby commented Mar 2, 2017

Copy link
Copy Markdown
Member Author

Great, that should be all nicely squashed up now.

QuLogic left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

One more minor thing.

The `matplotlib.patches.Arc` patch is now correctly drawn between the given
angles.

Previously a circular are was drawn and then stretched into an ellipse,

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

are -> arc

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

woops...

QuLogic changed the title Correct theta values when drawing a non-circular arc [MRG+1] Correct theta values when drawing a non-circular arc Mar 9, 2017
NelleV merged commit beeba66 into matplotlib:master Mar 10, 2017
QuLogic changed the title [MRG+1] Correct theta values when drawing a non-circular arc Correct theta values when drawing a non-circular arc Mar 11, 2017
dstansby deleted the arc-theta branch April 2, 2017 16:44
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
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

Successfully merging this pull request may close these issues.

5 participants


Back | FazBrowse Home | New Git URL