On 10/7/05, Robert Kern <rkern@...> wrote:
> John Hunter wrote:
> >>>>>>"Paul" =3D=3D Paul Barrett <pebarrett@...> writes:
> > Paul> I have data that has error bars and upper limits. (Actually
> > Paul> they are lower limits, since the Y axis is in stellar
> > Paul> magnitudes and is inverted.) My suggestion is use a negative
> > Paul> error value to indicate a limit in which case an arrow would
> > Paul> be drawn, instead of an error bar. This feature would only
> > Paul> apply to the case of asymmetric error bars and not to the
> > Paul> symmetric case. I can produce a patch if this suggestion is
> > Paul> agreeable.
> > I certainly don't have a problem with this and would be happy to
> > include these extensions to the errorbar function. I wonder if the
> > arrow is the best indicator for a limit, though I can't think of a
> > better one at the moment. Also, does this handle limits in either
> > direction (up or down) as well as left to right?
> Arrows are often used to indicate error bars which end outside of the
> displayed area of the plot. I would also recommend against using
> negative error values to indicate limits instead of errors. It smells of
> FORTRAN. :-)
Yes, it does smell of FORTRAN. However, my motive for suggesting negative
error values is that it allows the user to specify the length of the limit
arrow and numeric arrays to be used for input. The other option would be to
use a string, e.g.'limit(2)', as a marker. This will complicate the
implementation, but that is less of a concern to me than usability. I think
that the ability to specify the length of the arrow is needed. This could b=
an optional parameter though. I'm open to suggestions.
Limits should probably be implemented by a separate
In astronomy, limit data is often associated with data having large error
bars, i.e. they go hand-in-hand. So, a separate function would essentially
duplicate the error bar functionality. I see no need for this duplicity.