Eric Firing wrote:
> Sorry for the delay in looking at your patch.
> I am not familiar with this type of plot, as opposed to ordinary
> errorbars. What is it used for? What is the meaning of the upper and
> lower limits?
Sometimes physicist or astronomers want to indicate that a certain
measurement only given an upper- or lower-limit for a _measured value_,
which means that the true value can not directly be measured.
One example is the mass of the (electron)-neutrino which is not
known, but some experiments indicate that it has to be smaller than some
M +- dM. In such a case one would use an arrow pointing downwards to
indicate that this measurement only gives an upper limit for the mass.
Another example is the inferred mass of satellite galaxies of the
Milky Way. Here some measurements give the minimum mass of the galaxies,
while its total mass might be larger; in this case one wants to indicate
a lower limit, i.e. use an error-bar with an arrow pointing upwards.
So, the basic meaning is: you can derive a value and its formal
uncertainties, but you *know* that this value is only an
upper-/lower-limit of the true value; this is indicated by the arrow.
> The errorbar docstring will need to be modified to explain the new
> kwargs. Additional comments are interspersed below.
> Manuel Metz wrote:
>> I have attached a patch that adds the ability to draw upper/lower
>> limits indicators for errorbars. New keyword args had to be introduced
>> to the errorbar command, and I also had to add new plot styles. I
>> chose 'y','Y','z' and 'Z' as new linestyles for arrowheads pointing
>> up,down, left, right (see lines.py).
> These markers seem to me to be very special, more similar to the
> TICKLEFT and friends than to the general-use markers for which letters
> are assigned. Since there is nothing mnemonic about your suggested
> letter assignments, I think it would be better not to further clutter
> that list of letters, and instead to extend the list of tick-like
> things. I suggest calling them CARETUP, CARETDOWN, etc, since they seem
> to me more like carets than anything else. The change to names from
> single characters will make the code in the errorbar method more readable.
>> An example and its output is also attached.
>> Eric: I know, I don't use masked array in this patch ;_) . The reason
>> was that errorbar() also doesn't use them, and a did not want to
>> completely change that function but just add the new feature.
>> Switching to masked arrays should be straight forward, I think :-)
>> Index: axes.py
>> --- axes.py (revision 3727)
>> +++ axes.py (working copy)
>> @@ -3554,7 +3554,30 @@
>> if 'lw' in kwargs:
>> + + lolims = uplims = False
>> + xlolims = xuplims = False
>> + if 'lowerlimits' in kwargs:
>> + lolims = kwargs.pop('lowerlimits')
>> + if 'upperlimits' in kwargs:
>> + uplims = kwargs.pop('upperlimits')
>> + if 'xlowerlimits' in kwargs:
>> + xlolims = kwargs.pop('xlowerlimits')
>> + if 'xupperlimits' in kwargs:
>> + xuplims = kwargs.pop('xupperlimits')
> Instead of using **kwargs and popping them, the new kwargs should be
> part of the signature. This would be consistent with the present
> signature, in which **kwargs is used only to pass additional marker
>> + + if not iterable(lolims): lolims =
>> npy.asarray([lolims]*len(x), bool)
> Minor point: here (above) you *know* you are not starting with an array,
> so it would be clearer and more efficient to use npy.array, reserving
> npy.asarray for the case below where you *don't* know whether the
> argument is an array or not.
>> + else: lolims = npy.asarray(lolims, bool)
> The main thing I need from you is the modified docstring, although a new
> patch incorporating that and the other suggested changes would be even
I modified the docstring, but I'm also sure that it might need some
further adjustments ... ;-)
I also tried to incorporate all your suggestions made about the
marker-symbols, keywords and usage of asarray<->array.