Re: [Matplotlib-users] default error bar color

[John H. <jdh...@ac...>]

>>>>> "Jin-chung" == Jin-chung Hsu <hs...@st...> writes:

    Jin-chung> When using the errorbar(), I have no way to change the
    Jin-chung> marker size (except do a separate plot()).  Should we
    Jin-chung> add that to the errorbar's argument list?

Hi Jin-chung,

You can change the marker size with 

  1 >>> l, el = errorbar(x, y, fmt='ro',yerr=yerr)
  2 >>> set(l, ms=12)

The first return arg of errorbar is the marker line, and the second
the errorbar lines.  Abbreviations in the kwargs (eg ms for
markersize) were introduced in 0.61.

    Jin-chung> Also there is another inconsistency between plot() and
    Jin-chung> errorbar(), the latter needs the fmt argument, but the
    Jin-chung> former does not recognize it.

The fact that plot doesn't recognize fmt as a kwarg stems from the
fact that it uses positional args for multiple lines and kwargs to set
line properties.  The fact that you can do anf of the following and
more

    a.plot(x,y)            # plot Numeric arrays y vs x
    a.plot(x,y, 'bo')      # plot Numeric arrays y vs x with blue circles
    a.plot(y)              # plot y using x as index array 0..N-1
    a.plot(y, 'r+', antialiased=False, alpha=0.5)
    a.plot(x1, y1, 'g^', x2, y2, 'ro')        # arbitrary number of lines
    a.plot(x1, y1, x2, y2, 'g-', linewidth=2) # w/ or w/o fmt strings

means plot is already stretched to its limit in processing variable
numbers and types of arguments!  All kwargs are assumed to be line set
methods, and Line2D doesn't have a set_fmt method.  The line class
doesn't know about format strings.

    Jin-chung> Another comment about errorbar() is that the error bar
    Jin-chung> should not show in the marker face area, i.e the error
    Jin-chung> bars should be drawn first and then the markers with no
    Jin-chung> transparency.

Isn't this debatable?  Might someone want to see the errorbar range in
front of or behind a large marker with transparency?  Why do you say
this with certainty?

I agree there is a serious limitation in the way the axes draws it
objects - it's too rigid.  The following order is used: frame, images,
axis, patches, lines, text, title, legend, table.

I've been thinking about how to fix this and I think it will be easy.
Assign a buoyancy to each Artist (Line2D, Text, Rectangle, etc are all
derived from Artist).  The higher the buoyancy, the greater the
tendency to float to the top.  Choose defaults in the range of 0..10
(or some other range), and assign default numbers like

  frame   : 2
  images  : 2.5
  axis    : 3 
  patches : 4  (rectangles, polygons and such)
  lines   : 5
  text    : 6
  title   : 7   and so on

The user, of course, could override the number for any object.  Eg

    markerline, errlines = errorbar(*args)
    set(markerline, buoyancy=5.5)   # move it up a little
    set(errlines,   buoyancy=4.5)   # move it down a little

Because all the artists have the same drawing signature, it would be
easy to put them in a list of ( buoyancy, artist) tuples, sort them,
and draw them all.  This would give you the ability to control the
rendering order.

It's so easy to do that I could implement it faster than I can
describe it, but I think buoyancy is a bad name (too hard to spell),
and I wanted to get some feedback on the idea.  Should large numbers
be drawn last or first (last is my instinct, like list indexing, and
more efficient since you won't have to reverse the sort).  What is a
good attribute name?  I think a method like scale_buoyancy would be
useful too so users wouldn't have to know the default values.  Eg, in
the marker example you could scale the buoyancy of the errorlines by
0.9 and the marker lines by 1.1.  Any thoughts?

Once this structure is in place, it would be easy to change the
default order of errorbar and marker on the plot.  But I would like
some defense of the idea that the order you propose is the right one,
and/or input from others.

    Jin-chung> In 0.61.0, the marker edge color is still black,
    Jin-chung> instead of being the same as the marker face color.
    Jin-chung> Personally, I think they should be the same.  What do
    Jin-chung> people think?

    Jin-chung> One reason for the same color argument is that if the
    Jin-chung> markersize is set to a small value, it will show mostly
    Jin-chung> the edge color.

    Jin-chung> One possible reason against it is that if the marker
    Jin-chung> color is white (or whatever the background color is),
    Jin-chung> then you can't see the marker.  But we can default this
    Jin-chung> case to black (or whatever).

I tend to prefer the black marker edge color - I think it looks a
little better.  I'm willing to be persuaded.  Note that for regular
plot commands (not yet for errorbar) you can do

  plot(x, y, 'bo', mec='b') 

I would like to support 'lines.markeredgecolor : None' in rc, but None
is already doing double duty in the Line2D constructor and means "use
the rc value".  I could introduce a new value 'Same' or the string
'None' as opposed to the symbol None for this purpose, or something to
that effect.

For errorbars, since they don't accept all the kwargs that plot
does (the situation is more complex since you have the markers and the
error lines) you have to use the

  1 >>> l, el = errorbar(x, y, fmt='ro',yerr=yerr)
  2 >>> set(l, mec='r', ms=12)

incantation.

    Jin-chung> In 0.61.0, when plotting a simple array with error
    Jin-chung> bars, the default color of the error bars is black,
    Jin-chung> instead of being the same as the line/markers color,
    Jin-chung> e.g.:

    >>>> errorbar([1,2,3,4,5],[3,4,5,6,7],fmt='ro',yerr=[1,1,1,1,1])

    Jin-chung> I prefer them to be the same, especially since the
    Jin-chung> default color for marker/line is blue and a beginner
    Jin-chung> may be surprised to see the different color.

Fixed in CVS.  The ecolor param defaults to None, in which case the
marker color is used.  You can override this by specifying an ecolor
value.

Thanks for the comments,
JDH