Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Ensure that Path.arc works for any full circle. #8994

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

Merged
merged 4 commits into from
Aug 7, 2017

Conversation

QuLogic
Copy link
Member

@QuLogic QuLogic commented Aug 5, 2017

Depending on the inputs, the range may get squashed down to ~0 when trying to remove extra 2pi revolutions.

This condition is part of implementation linked in the docstring for Path.arc but is not included here for some reason.

Fixes #8992.

PR Checklist

  • Has Pytest style unit tests
  • Code is PEP 8 compliant
  • [N/A] New features are documented, with examples if plot related
  • [N/A] Documentation is sphinx and numpydoc compliant
  • [N/A] Added an entry to doc/users/next_whats_new/ if major new feature (follow instructions in README.rst there)
  • [N/A] Documented in doc/api/api_changes.rst if API changed in a backward-incompatible way

@QuLogic QuLogic added this to the 2.1 (next point release) milestone Aug 5, 2017
@QuLogic
Copy link
Member Author

QuLogic commented Aug 5, 2017

It's never that easy, is it...

The failing test seems possibly both wrong and right.
wedge_range

The top left circle is fully 0-380 now, instead of the expected 0-20 (this is debatably correct now.) The expected bottom centre circle was supposed to look like the bottom left; this is probably a precision issue as it's inputting an arc that's ~180 degrees wide.

QuLogic added 3 commits August 6, 2017 00:48
These trig bits were necessary to properly scale by major and minor axes
for an ellipse, but this method only supports circular arcs.
Depending on the inputs, the range may get squashed down to ~0 when
trying to remove extra 2pi revolutions.

Fixes matplotlib#8992.
These are a bit unfortunate since they're mostly invisible.
eta2 = np.arctan2(np.sin(theta2), np.cos(theta2))
eta2 -= twopi * np.floor((eta2 - eta1) / twopi)
eta1 = theta1
eta2 = theta2 - 360 * np.floor((theta2 - theta1) / 360)
Copy link
Member

Choose a reason for hiding this comment

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

Why use floor instead of // ?

Copy link
Member Author

Choose a reason for hiding this comment

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

There are a few edge cases where it's not the same, but I'm not sure if that's the reason. This is just a rearrangment of existing code changed from radians to degrees (because the trig is not necessary here.)

@QuLogic
Copy link
Member Author

QuLogic commented Aug 6, 2017

I forgot to comment after pushing, but I found that there's some trig that's unnecessary which produces some small floating-point inconsistencies. It's there to scale by ellipses major & minor axes, but arc only supports circles, so I've dropped it.

@tacaswell
Copy link
Member

Can you add a note to the docstring that this always draws from theta1 -> theta2 clockwise and winding at most once?

I don't think this is a change of behavior, but there is some ambiguity as to what it should do (for example it could wind multiple times (which I don't think any one wants) or it could always connect them via the shortest route (which I also think no one wants)).

@QuLogic
Copy link
Member Author

QuLogic commented Aug 7, 2017

That's correct; it's the existing behaviour, and I've added some lines explaining it.

@WeatherGod WeatherGod merged commit 70f0136 into matplotlib:master Aug 7, 2017
@QuLogic QuLogic deleted the fix-full-arc branch August 7, 2017 20:45
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.

3 participants