It is by pure convention that angles are usually measured counter-clockwise, but there are some good reasons for that; https://en.wikipedia.org/wiki/Right-hand_rule#Coordinates, https://en.wikipedia.org/wiki/Orientation_(vector_space), https://en.wikipedia.org/wiki/Complex_number#Exponentiation Of course this is again based on the convention of the x axis being the horizontal axis and denoting ordinates and in the end one could of course define everything just the other way around. But I suppose it makes sense for matplotlib to follow those conventions and hence define the direction of the arc in counter-clockwise direction.

I do agree that this is not very obvious from the documentation. While matplotlib.patches.Arc at least tells that its angle is "anti-clockwise" such that theta1 and theta2 need to follow this implicitely, matplotlib.path.Path.arc does not mention orientation at all.

I will hence label this with "documentation". Though, if you think that this issue is not solved by clearly stating in the docs that arcs are defined counter-clockwise, please feel free to clarify.

Hej,

first of all I want to point out my gratitude for the entire matplotlib-team's valuable and good work, that slipped my attention in the initial posting :)

Now concerning the issue:

I am aware of the convention, but from the documentation it wasn't clear that it would be enforced instead of sticking to the input logic, so I think adjusting the documentation would be very helpful. Further, if one does not think with a certain direction in mind, I think that the expression "produce the shortest arc within 360 degrees" could actually suggest that the arc is never longer than 180 degrees (Yay to the pain that is angle wrapping).

Now as for the functionality:

The following is very subjective and quite possibly influenced by my very limited knowledge of the path module and bezier curves.
I understand the arc method as a convenience function to produce arc segments without wrestling with Beziercurves manually. I have used it to produce arc segments that are intended to be parts of a longer closed path. In such a path I have no control over the sense of rotation that an arc has to follow, therefore having the possibility to create clockwise arcs would definitely be useful.
I do, however, understand that changing the behaviour of the arc method could have dire consequences for any derived code, so it would probably have to come with a default flag as an input parameter.

If you prefer to leave the functionality as it currently is, maybe the following snippet could be added to documentation, I have finally figured out how to traverse the arc in the direction I want without changing the code of path.arc itself.

if t0 <= t1:
    arc = Path.arc(t0, t1)
if t0 > t1:
    arc = Path.arc(t1, t0)
    codes = list(arc.codes[:])
    verts = list(arc.vertices[:])
    verts = verts[::-1]
    codes = codes[::-1]
    codes[0], codes[-1] = codes[-1], codes[0]
    arc = Path(verts, codes)

EDIT: Improved snippet readability

Thanks for the detailing this; to summarize, there are two action items here:

• Document the orientation of Arcs.
• Add an option to create clockwise arc paths.

Nice :) If I find some time in the upcoming week I will try to test how bulletproof the current and modified angle wrapping logic are and potentially make a pull request :)

I wonder if it would make more sense to have a generic Path().reverse() method, rather than having to add this functionality to each path generator separately (in fact, it's basically already there (privately) as Sankey._revert (modulo what to do with the first point, and likely mishandling of CLOSEPOLY)).

This issue has been marked "inactive" because it has been 365 days since the last comment. If this issue is still present in recent Matplotlib releases, or the feature request is still wanted, please leave a comment and this label will be removed. If there are no updates in another 30 days, this issue will be automatically closed, but you are free to re-open or create a new issue if needed. We value issue reports, and this procedure is meant to help us resurface and prioritize issues that have not been addressed yet, not make them disappear. Thanks for your help!