On 10/7/05, Robert Kern <rkern@ucsd.edu> wrote:
John Hunter wrote:
>>>>>>"Paul" == Paul Barrett <pebarrett@gmail.com> 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 be an optional parameter though. I'm open to suggestions.

Limits should probably be implemented by a separate
object/function/whatever.

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.

 -- Paul