http://matplotlib.org/examples/statistics/errorbar_limits.html is another way this can be dealt with which requires a bit more user input to interpret what and 'infinite' errorbar means.

It might be possible to automatically do something like that in the case of inf.

I think another reasonable approach to the error being inf is to drop the point altogether (likely making too many assumptions to be in mpl) as if the error is infinite, then the number is effectively meaningless.

Thanks for the link but it does not really help in my situation.
maybe some more context.
At the moment I want to plot a histogram (I am actually binning the data myself and then use errorbar to plot it) with error bars. The problem arises if you have a bin with a single entry.
With that, the std becomes infinite. At the moment, I cannot make a difference between the bins which have a finite and very small error and bins which basically have no information at all. They are displayed the same which is really really irritating.

If instead inf errors would fill the complete direction (but not count towards the limits), I would show this difference. Also, if I prefer to not have this range filling error bar, I can just replace infs with nans and have the old back.

Hi,

well, its math, if you have a Bessel correction in your error formular( i.e. 1/(N-1)) the error will always become infinite for singular events which makes total sense. A singular measurement does usually tell you nothing which is indicated by a infinite error on the value (you get the same for a fit through a singular data point, the parameters will be random with an infinite error). If you pick a different error formular, you might not get to inf but most error formuars I know contain a Bessel correction due to being an estimator to the actual error because the actual error is normally not known.

Either way, its not matplotlib which should decide to drop this from my plotting but me. And displaying an error bigger then the frame will 1. indicate to the user what is going on at the data point, if he does not like it, he can either revert to the nan behaviour very easily or choose some other way to reflect this) 2. does not get confused with an nonexistent or close to 0 error bar.

While I agree with @efiring that infinite error doesn't make sense, I agree with @FrederikLauber on deferring to the user. I support the idea of just extending a line to the axis extent as that technically won't change the API. inf yerr would be plotting infinite lines relative to the (x,y) point. I'm not sure, but it may also be sorta consistent with the idea of #5253 that sometimes lines are supposed to just extend.

Maybe matplotlib should raise a warning as to that being what it's doing, but that might be clutter...

I am running into this issue in the context of a forest-plot-style comparison of median estimates from survival regressions. I am using the (2,N) shaped form of xerr. Frequently in survival regression, e.g. a Kaplan-Meier estimator, the lower bound of the median and the point estimate of the median are both well-defined, but the upper bound is not. I wish there were some way to have the error in that direction continue to the edge of the frame.

@zmbc You should look at the lolims and uplims keyword arguements https://matplotlib.org/stable/api/_as_gen/matplotlib.axes.Axes.errorbar.html#matplotlib-axes-axes-errorbar which exist for the purpose of indicating that only one of the bounds should be trusted.

Yes, I vote that this be closed...

@tacaswell I did, and unless I'm missing something lolims and uplims can't do what I want. As you can see in this example, using lolims or uplims to give one error direction an arrow necessarily removes the error in the other direction. In my use case, there is a well-defined lower bound, which I want to display, and also an upper bound that is unknown.

Can you get the desired effect by substituting a very large number for the inf and then manually set the desired ylim for the plot?

@zmbc 🐑 Sorry, I answered too quickly and was mistaken about exactly what that API did (I remembered the arrow up/down, but not that it dropped the other side).

I am inclined to re-open this (or open a new issue) to track the request from "real error in one direction, line with arrow in the other".

I am not sure that "off the screen" is the right thing for us to ever do by default because that suggest that there might be a real value out there if you changed the limits right (and I do not recall off the top of my head if auto-limits take in to account error bars...I hope they do). I think the right thing is something like |----O----> (with a real error to the left and a "goes that way" error to the right).

Good idea @efiring, I will do that for now.

I agree that the arrow would be preferable to an infinitely-extending line.

I opened #22980 to track the idea of using an arrow...