[matplotlib-devel] patches for: bar() and barh() ignore rcparams patch.facecolor and patch.endcolor
Well, I seem to have really dove into this.
Here are 4 different patches against the latest svn of axes.py (rev
2495). Note that the rest of my install is the 0.87.3 release (I had to
copy over quiver.py to get the latest axes.py to work).
patch1 has the following changes to bar() and barh():
- fixed ignoring the rcParams['patch.facecolor'] for bar color: the
default value for the color arg is now None, and the Patch class is left
to handle fetching the rcparams['patch.facecolor']
- set default error bar color to None, so that errorbar() can handle
fetching the rcParams['lines.color']
- added an edgecolor keyword arg
- left and height can now both be scalars in bar(), same goes for x and
y in barh(). Previously, this raised a TypeError upon testing their
lengths. Code that preventively checked for this in barh() (but not in
bar()) has been removed.
- fixed a bug where patches would be cleared when error bars were
plotted if rcParams['axes.hold'] was False
- it looks like the code for barh() was copied from bar(), with some of
the args renamed. There was an error in the color checking code in
barh() where len(left) from bar() hadn't been properly renamed to len(x)
- found one or two changes that had been made to bar() that hadn't been
propagated to barh(), or vice versa
- rearranged the order of some code segments so that they follow the
order of the arguments
- updated the docstrings
Hopefully I haven't introduced any new bugs.
patch2 has everything in patch1, except it removes some code duplication
by calling bar() from within barh(). I thought this would be a good
idea, since it's easy to make a change in bar() and forget to do the
same in barh(). It turns out that this takes up almost as many lines of
code as having two independent functions, but this is only due 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.
So... patch3 has everything in patch2, but renames the x and y args in
barh() to width and bottom respectively. This makes barh() draw bars
vertically aligned to their bottom edge, consistent with bar()'s
behaviour. Also, this makes hist(orientation='horizontal') do the same,
which makes it consistent with hist(orientation='vertical'). Finally, it
removes the code bloat mentioned above. However, it'll break any
existing code that relies on x or y as named args in barh(), or code
that expects barh() bars to be vertically centered on their y values.
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 don't know if anyone agrees with this change, but patch4 has all of
the changes in patch3, plus the order of the width and bottom args are
switched in barh(). This of course will break existing code that depends
on this order. I had to modify the barh() call in
hist(orientation='horizontal') to reflect this. I couldn't find any
other barh() call in matplotlib. For consistency, I also switched the
order of the yerr and xerr args, but these have default values and are
usually passed as keyword args, so this shouldn't break (much) code.
The patches are numbered in increasing order of preference. They look
rather big (and I'm not sure if my file compare util is bug-free). If
there seem to be problems with them, I can provide the full axes.py file
that corresponds to each patch.
Cheers,
Martin
--- C:\home\mspacek\Desktop\axes.svn2495.py 2006-06-20 16:56:06.0
-0700
+++ C:\home\mspacek\Desktop\axes.patch1.py 2006-06-22 03:31:27.0
-0700
@@ -2090,13 +2090,13 @@
autoscaled; default True. See Axes.autoscale_view for more
information
"""
d = kwargs.copy()
scalex = d.pop('scalex', True)
-scaley = d.pop('scaley', True)
+scaley = d.pop('scaley', True)
if not self._hold: self.cla()
lines = []
for line in self._get_lines(*args, **d):
self.add_line(line)
lines.append(line)
l
Re: [matplotlib-devel] patches for: bar() and barh() ignore rcparams patch.facecolor and patch.endcolor
> "Martin" == Martin Spacek <[EMAIL PROTECTED]> writes: Hey martin, thanks for all these changes. Martin> to inconsistent behaviour: barh() draws bars vertically Martin> centered on the y values (ala matlab 6.0), while bar() Martin> draws bars aligned according to their left edge (not ala Martin> matlab). I prefer the edge aligning behaviour. It's easy Martin> to convert from one behaviour to the other, but I had to Martin> duplicate all the error checking code before conversion, Martin> 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. Martin> And lastly... I find it odd that barh() has the width and Martin> bottom args (formerly x and y) in that order: barh(width, Martin> bottom). The general matlab convention is that the first Martin> argument is the positions, and the second arg is the Martin> values. So it would make more sense to me to have Martin> barh(bottom, width). That way, you could switch back and Martin> forth between bar() and barh() and get the expected Martin> behaviour without having to switch around the Martin> arguments. In fact, that's exactly how barh() in matlab 6 Martin> interprets the first two arguments: arg1 is the vertical Martin> positions, and arg2 is the lengths of the bars at those Martin> positions. Same goes for matlab's bar() function. As it is Martin> now in matplotlib, the first and second arguments are Martin> 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 All the advantages of Linux Managed Hosting--Without the Cost and Risk! Fully trained technicians. The highest number of Red Hat certifications in the hosting industry. Fanatical Support. Click to learn more http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Unicode to Tex symbols, Type1 names, and vice versa
I finally solved the problem of automaticaly generating the dicts for
unicode <-> TeX conversion. This is the first step in enabling unicode
support in mathtext.
The STIX projects is usefull after all ;) They keep a nice table of
Unicode symbols at:
http://www.ams.org/STIX/bnb/stix-tbl.ascii-2005-09-24
Any comments about the script are appreciated :). Now I'll dig a bit
deeper into the font classes to fix them to suport unicode.
'''A script for seemlesly copying the data from the stix-tbl.ascii*
file to a set
of python dicts. Dicts are then pickled to coresponding files, for
later retrieval.
Currently used table file:
http://www.ams.org/STIX/bnb/stix-tbl.ascii-2005-09-24
'''
import pickle
table_filename = 'stix-tbl.ascii-2005-09-24'
dict_names = ['uni2type1', 'type12uni', 'uni2tex', 'tex2uni']
dicts = {}
# initialize the dicts
for name in dict_names:
dicts[name] = {}
for line in file(table_filename):
if line[:2]==' 0':
uni_num = eval("u'\\u"+line[2:6].strip().lower()+"'")
type1_name = line[12:37].strip()
tex_name = line[83:110].strip()
if type1_name:
dicts['uni2type1'][uni_num] = type1_name
dicts['type12uni'][type1_name] = uni_num
if tex_name:
dicts['uni2tex'][uni_num] = tex_name
dicts['tex2uni'][tex_name] = uni_num
for name in dict_names:
pickle.dump(dicts[name], open(name + '.pcl','w'))
# An example
uni_char = u'\u00d7'
print dicts['uni2tex'][uni_char]
print dicts['uni2type1'][uni_char]
# Testing of results, testing; feel free to unquote
# _mathtext_data.py can be found in the matplolib dir
#~ from _mathtext_data import latex_to_bakoma
#~ supported = 0
#~ unsupported = 0
#~ for tex_symbol in latex_to_bakoma:
#~ try:
#~ print tex_symbol, dicts['tex2uni'][tex_symbol]
#~ supported += 1
#~ except KeyError:
#~ unsupported += 1
#~ pass
#~ print supported, unsupported
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Unicode to Tex symbols, Type1 names, and vice versa
> "Edin" == Edin Salkovi§ <[EMAIL PROTECTED]> writes:
Edin> I finally solved the problem of automaticaly generating the
Edin> dicts for unicode <-> TeX conversion. This is the first step
Edin> in enabling unicode support in mathtext.
Excellent.
Edin> The STIX projects is usefull after all ;) They keep a nice
Edin> table of Unicode symbols at:
Edin> http://www.ams.org/STIX/bnb/stix-tbl.ascii-2005-09-24
Edin> Any comments about the script are appreciated :). Now I'll
Since you asked :-)
I may not have mentioned this but the style conventions for mpl code
are
functions : lower or lower_score_separated
variables and attributes : lower or lowerUpper
classes : Upper or MixedUpper
Also, I am not too fond of the dict of dicts -- why not use variable
names? Here is my version
import pickle
fname = 'stix-tbl.ascii-2005-09-24'
uni2type1 = dict()
type12uni = dict()
uni2tex = dict()
tex2uni = dict()
for line in file(fname):
if line[:2]!=' 0': continue # using continue avoids unneccesary indent
uninum = line[2:6].strip().lower()
type1name = line[12:37].strip()
texname = line[83:110].strip()
uninum = int(uninum, 16)
if type1name:
uni2type1[uninum] = type1name
type12uni[type1name] = uninum
if texname:
uni2tex[uninum] = texname
tex2uni[texname] = uninum
pickle.dump((uni2type1, type12uni, uni2tex, tex2uni),
file('unitex.pcl','w'))
# An example
unichar = int('00d7', 16)
print uni2tex.get(unichar)
print uni2type1.get(unichar)
Also, I am a little hesitant to use pickle files for the final
mapping. I suggest you write a script that generates the python code
contains the dictionaries you need (that is how much of _mathext_data
was generated.
Thanks,
JDH
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] changes to collections, etc.
I have commited a set of changes to _transforms, collections, quiver, contour, and numerix as part of a move toward taking advantage of the efficiency of numerix arrays in place of sequences of tuples. The changes are outlined very briefly in CHANGELOG and API_CHANGES. Changes in clabel are hacks, and may make it less efficient rather than more, but I expect this to be temporary; I needed to simply make it work with the other changes. Where breakage will occur is any place in user code that expects the collection segments or vertices to be lists of tuples and tries to append to the list, for example. I don't know of any way to make the move towards use of arrays without this problem cropping up; I hope it is considered tolerable. Eric Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] changes to collections, etc.
> "Eric" == Eric Firing <[EMAIL PROTECTED]> writes: Eric> Where breakage will occur is any place in user code that Eric> expects the collection segments or vertices to be lists of Eric> tuples and tries to append to the list, for example. I Eric> don't know of any way to make the move towards use of arrays Eric> without this problem cropping up; I hope it is considered Eric> tolerable. If I'm understanding you correctly: Users who create the collection themselves with the list of xy tuples approach can still modify their lists, eg with append, and not have breakage (I actually use this feature). But users who are getting collections back from code like contour will get the non-modifiable array version. Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] changes to collections, etc.
John Hunter wrote: >>"Eric" == Eric Firing <[EMAIL PROTECTED]> writes: > > > Eric> Where breakage will occur is any place in user code that > Eric> expects the collection segments or vertices to be lists of > Eric> tuples and tries to append to the list, for example. I > Eric> don't know of any way to make the move towards use of arrays > Eric> without this problem cropping up; I hope it is considered > Eric> tolerable. > > If I'm understanding you correctly: Users who create the collection > themselves with the list of xy tuples approach can still modify their > lists, eg with append, and not have breakage (I actually use this > feature). But users who are getting collections back from code like > contour will get the non-modifiable array version. > > John, Yes, that is the way it is supposed to work. The collection stores and uses whichever form it is given. This can work because the XY array is very similar to the [(x,y), (x,y)...] form; both are single objects, and they behave the same when one says, "for xy in XY:", or if one calls the array constructor with either as an argument. Eric Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] patches for: bar() and barh() ignore rcparams patch.facecolor and patch.endcolor
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 --- C:\home\mspacek\Desktop\axes.svn2508.py 2006-06-22 19:04:36.0 -0700 +++ C:\home\mspacek\Desktop\axes.patch5.py 2006-06-22 23:10:53.0 -0700 @@ -2361,185 +2361,243 @@ Specialized plotting def bar(self, left, height, width=0.8, bottom=0, -color='b', yerr=None, xerr=None, ecolor='k', capsize=3 +color=None, edgecolor=None, yerr=None, xerr=None, ecolor=None, capsize=3, +align='edge', orientation='vertical' ): """ BAR(left, height, width=0.8, bottom=0, -color='b', yerr=None, xerr=None, ecolor='k', capsize=3) +color=None, edgecolor=None, yerr=None, xerr=None, ecolor=None, capsize=3, +align='edge', orientation='vertical') -Make a bar plot with rectangles at +Make a bar plot with rectangles bounded by - left, left+width, 0, height + left, left+width, bottom, bottom+height (left, right, bottom and top edges) -left and height are Numeric arrays. +left, height, width, and bottom can be either scalars or sequences Return value is a list of Rectangle patch instances BAR(left, height, width, bottom, -color, yerr, xerr, capsize, yoff) +color, edgecolor, yerr, xerr, ecolor, capsize, +align, orientation) +left - the x coordinates of the left sides of the bars + +height - the heights of the bars + +Optional arguments + +width - the widths of the bars + +bottom - the y coordinates of the bottom edges of the bars + +color specifies the colors of the bars + +edgecolor specifies the colors of the bar edges + xerr and yerr, if not None, will be used to generate errorbars - on the bar chart +on the bar chart -color specifies the color of the bar - ecolor specifies the color of any errorbar capsize determines the length in points of the error bar caps +align = 'edge' | 'center' -The optional arguments color, width and bottom can be either -scalars or len(x) sequences +orientation = 'vertical' | 'horizontal' + +For vertical bars, 'edge' aligns bars by their left edges in left, +while 'center' interprets these values as the x coordinates of the bar centers. +For horizontal bars, 'edge' aligns bars by their bottom edges in bottom, +while 'center' interprets these values as the y coordinates of the bar centers. + +The optional arguments color, edgecolor, yerr, and xerr can be either +scalars or sequences of length equal to the number of bars This enables you to use bar as the basis for stacked bar charts, or candlestick plots """ if not self._hold: self.cla() -# left = asarray(left) - width/2 +def make_iterable(x): +if not iterable(x): +return [x] +else: +return x + +# make them safe to take len() of +left = ma
