patches for: bar() and barh() ignore rcparams patch.facecolor and patch.endcolor

Hey martin, thanks for all these changes.

    > to inconsistent behaviour: barh() draws bars vertically
    > centered on the y values (ala matlab 6.0), while bar()
    > draws bars aligned according to their left edge (not ala
    > matlab). I prefer the edge aligning behaviour. It's easy
    > to convert from one behaviour to the other, but I had to
    > duplicate all the error checking code before conversion,
    > which bloated it back up.

Most people prefer the center aligning behavior, at least those who
complained on the list about bar, so when I wrote barh I adopted
this. I tried to fix bar in the process, but ended up running into
some bugs when I tested John Gill's table demo, and so left it as edge
aligned and haven't revisited it since. So my weak preference would
be to have the two functions consistent and center aligned, but he who
does the work usually gets the biggest vote. Maybe others can chime
in.
    > And lastly... I find it odd that barh() has the width and
    > bottom args (formerly x and y) in that order: barh(width,
    > bottom). The general matlab convention is that the first
    > argument is the positions, and the second arg is the
    > values. So it would make more sense to me to have
    > barh(bottom, width). That way, you could switch back and
    > forth between bar() and barh() and get the expected
    > behaviour without having to switch around the
    > arguments. In fact, that's exactly how barh() in matlab 6
    > interprets the first two arguments: arg1 is the vertical
    > positions, and arg2 is the lengths of the bars at those
    > positions. Same goes for matlab's bar() function. As it is
    > now in matplotlib, the first and second arguments are
    > interpreted differently for bar() and barh()

I was following the convention that the x arg goes first and the y
second, but I'm not wed to this. I don't mind breaking existing code
if this order seems more natural, and since we are mostly emulating
the matlab conventions in bar and barh, it makes some sense to strive
for consistency. Perhaps you could patch the CHANGELOG and
API_CHANGES file along with the rest which explains the changes.

JDH

Hi John,

John Hunter wrote:

Most people prefer the center aligning behavior, at least those who
complained on the list about bar, so when I wrote barh I adopted
this. I tried to fix bar in the process, but ended up running into
some bugs when I tested John Gill's table demo, and so left it as edge
aligned and haven't revisited it since. So my weak preference would
be to have the two functions consistent and center aligned, but he who
does the work usually gets the biggest vote. Maybe others can chime
in.

I suppose I'm a bit jaded towards edges because I tend to make histograms and not bar graphs, but we can have it both ways.

Here's patch5 (now against the latest axes.py rev 2508). It has everything in patch4, plus a keyword arg 'align' that lets you choose between aligning the bars according to their edges (left for vertical bars, bottom for horizontal bars) or their centers. The default is align='edge' for both bar() and barh(). Perhaps that should be changed to 'center' if most people prefer it that way. Also, the 'horizontal' boolean arg in patch4 has been renamed to 'orientation' and is now a string: either 'vertical' or 'horizontal', consistent with hist(). I also added the align arg to hist(), which just passes it on to bar() or barh().

I was following the convention that the x arg goes first and the y
second, but I'm not wed to this.

In barh(), Matlab does indeed order the args x, y, but interprets them as y, x (ie, position, value), which actually makes sense to me.

Perhaps you could patch the CHANGELOG and
API_CHANGES file along with the rest which explains the changes.

Sure. Here they are against their latest rev (2508 for both). Never done logs before, hope they're alright. What do you mean by "the rest"?

Cheers,

Martin

patch5.txt (15 KB)

API_CHANGES_patch.txt (1.04 KB)

CHANGELOG_patch.txt (1.43 KB)