I guess I'm confused. Is this a theta error? If so, it should be drawn as a curve and kept at the same radius as the data point?

If so, it should be drawn as a curve and kept at the same radius as the data point?

That is probably the ideal solution, yes. Similar to the lines not directly connecting the points, but uses some sort of curve. However, considering the current output this PR is clearly a step in the right direction, actually making it possible to use error caps.

On the other hand, it shouldn't be impossible to use an Arc instead and orient the caps pointing to the center. But if noone is implementing that, I'd clearly go for this solution in the meantime.

(One can also think about if the caps for errorbars in the other direction should be rounded or not?)

Yes, if we want to be exact, theta errors should be curved. However, personally, I would not be that pedantic. Errors should be reasonably small (or the visualization does not tell much anyway). And fore small errors, a straight theta-line is a reasonable approximation of the curve. So if somebody wants to implement curved theta bars, great. But I would live with straight that-bars, if that's all we can do with reasonable effort now.

That said, I can also see an argument for not supporting theta bars at all if they are not curved.

If you can see the tilt for uncentred bars, I assume you can also see that they are not curved?

The original (rejected) solution in PR#21006 looked like this:

fig = plt.figure()ax = plt.subplot(111, projection='polar')theta = np.arange(0, 2*np.pi, np.pi / 4)r = theta / np.pi / 2 + 0.5ax.errorbar(theta, r, xerr=0.15, yerr=0.1)ax.set_rlim(0, 2)

On the other hand, under different settings I believe that curved theta error is must have, consider following plot:

import matplotlib.pyplot as pltimport numpy as npfig = plt.figure(figsize=(10,10))ax = plt.subplot(111, projection='polar')theta = np.arange(0, 2*np.pi, np.pi / 4)r = theta / np.pi / 2 + 0.5ax.errorbar(theta, r, xerr=0.25, capsize=7, fmt="o")

Um, this is indeed awkward. Whether curved or not, the theta-error line should hit the data point.

Probably not the final call on polar error bars. Nevertheless, this PR fixes the caps for yerr and makes it a little less bad for xerr. So I approve as an improvement.

(One can also think about if the caps for errorbars in the other direction should be rounded or not?)
IMHO this is not needed. Caps are essentially markers of the end point. They don't make a statement on the orthogonal axis. I.e. a y-cap does not say anything about theta. - Even if you disagress, from a practical point of view, caps are small enough so that the difference between rounded arc and straight line is small.

Closes#441.

Closes#441.

This needs to go in the original description, a commit message, or you can link with the Description section in the right sidebar. Putting it here though, doesn't do anything. Unfortunately,#441 doesn't show up here to be linked, but if you go there,this PR shows up to be linked, which I've now done.

I have fixed the testing figure. Additionally I have fixed the issue with radial offset for large error bars, see below:

importmatplotlib.pyplotaspltimportnumpyasnpfig=plt.figure(figsize=(10,10))ax=plt.subplot(111,projection='polar')theta=np.arange(0,2*np.pi,np.pi/4)r=theta/np.pi/2+0.5ax.errorbar(theta,r,xerr=0.25,capsize=7,fmt="o")

Additionally I have done some experiments with curved error bars:

You can see proof of principle with code changeshere

And just to make decision even harder, here I show some bar graphs with error bars:

importmatplotlib.pyplotaspltimportnumpyasnpfig=plt.figure(figsize=(10,10))ax=plt.subplot(111,projection='polar')theta=np.arange(0,2*np.pi,np.pi/4)r=theta/np.pi/2+0.5ax.errorbar(theta,r,xerr=0.25,yerr=0.1,capsize=7,fmt="o")ax.bar(theta,r,width=0.4,bottom=0.0,alpha=0.5)

Straight:

And curved:

Nice! I guess the best thing now is to discuss it at the dev-call on Thursday? Feel free to join if you want!

(Personally, I think that the curved error bars is the way to go.)

I agree: The curved error bars is what we want.

This was discussed on the weekly call. The consensus was curved error bars and wait for it all to be ready for 3.7 rather than squeezing this in for 3.6 with straight lines.

We also discussed the interpolate step (private) feature ofPath to simplify making the curved lines.

This looks good to me. However, can it get an example for the gallery, and the what's-new link the example?

I have added an gallery example (just a simple one), but I am not sure that the link inwhat's new is valid.