matplotlib-devel Mailing List for matplotlib

John Hunter wrote:
>>>>>>"Eric" == Eric Firing <ef...@ha...> 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

>>>>> "Eric" == Eric Firing <ef...@ha...> 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.

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

>>>>> "Edin" =3D=3D Edin Salkovi=A7 <edi...@gm...> 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.=20
 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=20
 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 =3D 'stix-tbl.ascii-2005年09月24日'
 uni2type1 =3D dict()
 type12uni =3D dict()
 uni2tex =3D dict()
 tex2uni =3D dict()
 for line in file(fname):
 if line[:2]!=3D' 0': continue # using continue avoids unneccesary=
 indent
 uninum =3D line[2:6].strip().lower()
 type1name =3D line[12:37].strip()
 texname =3D line[83:110].strip()
 uninum =3D int(uninum, 16)
 if type1name:
 uni2type1[uninum] =3D type1name
 type12uni[type1name] =3D uninum
 if texname:
 uni2tex[uninum] =3D texname
 tex2uni[texname] =3D uninum
 pickle.dump((uni2type1, type12uni, uni2tex, tex2uni), file('unitex.pc=
l','w'))
 # An example
 unichar =3D 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

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

>>>>> "Martin" == Martin Spacek <sc...@ms...> 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

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