matplotlib-devel Mailing List for matplotlib

>>>>> "Abraham" == Abraham Schneider <ab...@cn...> writes:
 Abraham> Hi. Well, not sure anyone is interested in following up
 Abraham> on the config file issue, but if so, attached is a
 Abraham> complete version (sorry for the big size!). One class and
 Abraham> two functions were moved from __init__.py, but besides
 Abraham> that it's all new (and thus the non-patch). But at least
 Abraham> my quick tests shows it to be backwards compatible
 Abraham> (i.e. it can read the .matplotlibrc files, and rc(...)
 Abraham> was rewritten to work with the new system).
 Abraham> A very quick synopsis: config['text']['color'] = 'r'
 Abraham> config['text.color'] = 'g' config['text.c'] = 'b'
 Abraham> rc('text', color=(100, 100, 100))
I'm interested. I haven't had time to follow it closely yet, but I do
plan on taking a close look soon. One thing I would like to see is a
syntax like
rc.text.color = 'red'
I think by creating a proper class for the rc instance and text
attribute and overriding setattr and getattr appropriately, you can
achieve this.
FYI, I'll include some code I worked on over holiday investigating
using enthought traits for rc files which does support a syntax like
this. Note the usage of
 rc.lines.color = 'r'
Thanks for chugging along on this. When time permits, I know Fernando
is interested in joining in this discussion because we previously
discussed adopting a python based config file that allowed recursive
includes that might be usable both for ipython and matplotlib,
JDH
import sys, os, re
from traits import *
from matplotlib.cbook import is_string_like
from matplotlib.artist import Artist
doprint = True
flexible_true_trait = Trait(
 True, 
 { 'true': True, 't': True, 'yes': True, 'y': True, 'on': True, True: True,
 'false': False, 'f': False, 'no': False, 'n': False, 'off': False, False: False
 } )
flexible_false_trait = Trait( False, flexible_true_trait )
colors = {
 'c' : '#00bfbf',
 'b' : '#0000ff',
 'g' : '#008000',
 'k' : '#000000',
 'm' : '#bf00bf',
 'r' : '#ff0000',
 'w' : '#ffffff',
 'y' : '#bfbf00',
 'gold' : '#FFD700',	
 'peachpuff' : '#FFDAB9',	
 'navajowhite' : '#FFDEAD',	
 }
def hex2color(s):
 "Convert hex string (like html uses, eg, #efefef) to a r,g,b tuple"
 return tuple([int(n, 16)/255.0 for n in (s[1:3], s[3:5], s[5:7])])
class RGBA(HasTraits):
 # r,g,b,a in the range 0-1 with default color 0,0,0,1 (black)
 r = Range(0., 1., 0.)
 g = Range(0., 1., 0.)
 b = Range(0., 1., 0.)
 a = Range(0., 1., 1.)
 def __init__(self, r=0., g=0., b=0., a=1.):
 self.r = r
 self.g = g
 self.b = b
 self.a = a
 def __repr__(self):
 return 'r,g,b,a = (%1.2f, %1.2f, %1.2f, %1.2f)'%\
 (self.r, self.g, self.b, self.a)
def tuple_to_rgba(ob, name, val):
 tup = [float(x) for x in val]
 if len(tup)==3:
 r,g,b = tup
 return RGBA(r,g,b)
 elif len(tup)==4:
 r,g,b,a = tup
 return RGBA(r,g,b,a)
 else:
 raise ValueError
tuple_to_rgba.info = 'a RGB or RGBA tuple of floats'
def hex_to_rgba(ob, name, val):
 rgx = re.compile('^#[0-9A-Fa-f]{6}$')
 if not is_string_like(val):
 raise TypeError
 if rgx.match(val) is None:
 raise ValueError
 r,g,b = hex2color(val)
 return RGBA(r,g,b,1.0)
hex_to_rgba.info = 'a hex color string'
def colorname_to_rgba(ob, name, val):
 hex = colors[val.lower()]
 r,g,b = hex2color(hex)
 return RGBA(r,g,b,1.0)
colorname_to_rgba.info = 'a named color'
def float_to_rgba(ob, name, val):
 val = float(val)
 return RGBA(val, val, val, 1.)
float_to_rgba.info = 'a grayscale intensity'
Color = Trait(RGBA(), float_to_rgba, colorname_to_rgba, RGBA,
 hex_to_rgba, tuple_to_rgba)
def file_exists(ob, name, val):
 fh = file(val, 'r')
 return val
def path_exists(ob, name, val):
 os.path.exists(val)
linestyles = ('-', '--', '-.', ':', 'steps', 'None')
TICKLEFT, TICKRIGHT, TICKUP, TICKDOWN = range(4)
linemarkers = (None, '.', ',', 'o', '^', 'v', '<', '>', 's',
 '+', 'x', 'd', 'D', '|', '_', 'h', 'H',
 'p', '1', '2', '3', '4',
 TICKLEFT,
 TICKRIGHT,
 TICKUP,
 TICKDOWN,
 'None'
 )
class LineRC(HasTraits):
 linewidth = Float(0.5) 
 linestyle = Trait(*linestyles)
 color = Color
 marker = Trait(*linemarkers)
 markerfacecolor = Color
 markeredgecolor = Color 
 markeredgewidth = Float(0.5)
 markersize = Float(6) 
 antialiased = flexible_true_trait 
 data_clipping = flexible_false_trait 
class PatchRC(HasTraits):
 linewidth = Float(1.0) 
 facecolor = Color
 edgecolor = Color 
 antialiased = flexible_true_trait 
timezones = 'UTC', 'US/Central', 'ES/Eastern' # fixme: and many more
backends = ('GTKAgg', 'Cairo', 'FltkAgg', 'GD', 'GDK', 'GTK', 'Agg',
 'GTKCairo', 'Paint', 'PS', 'SVG', 'Template', 'TkAgg',
 'WX')
class RC(HasTraits):
 backend = Trait(*backends)
 numerix = Trait('Numeric', 'numarray')
 interactive = flexible_false_trait
 toolbar = Trait('toolbar2', 'classic', None)
 timezone = Trait(*timezones)
 lines = Trait(LineRC())
 patch = Trait(PatchRC())
rc = RC()
rc.lines.color = 'r'
if doprint:
 print 'RC'
 rc.print_traits()
 print 'RC lines'
 rc.lines.print_traits()
 print 'RC patches'
 rc.patch.print_traits()
class Patch(Artist, HasTraits):
 linewidth = Float(0.5)
 facecolor = Color
 fc = facecolor
 edgecolor = Color
 fill = flexible_true_trait
 def __init__(self,
 edgecolor=None, 
 facecolor=None,
 linewidth=None,
 antialiased = None, 
 fill=1,
 **kwargs
 ):
 Artist.__init__(self)
 if edgecolor is None: edgecolor = rc.patch.edgecolor
 if facecolor is None: facecolor = rc.patch.facecolor
 if linewidth is None: linewidth = rc.patch.linewidth
 if antialiased is None: antialiased = rc.patch.antialiased
 self.edgecolor = edgecolor
 self.facecolor = facecolor
 self.linewidth = linewidth
 self.antialiased = antialiased 
 self.fill = fill
 
p = Patch()
p.facecolor = '#bfbf00'
p.edgecolor = 'gold'
p.facecolor = (1,.5,.5,.25)
p.facecolor = 0.25
p.fill = 'f'
print 'p.facecolor', type(p.facecolor), p.facecolor
print 'p.fill', type(p.fill), p.fill
if p.fill_: print 'fill'
else: print 'no fill'
if doprint:
 print
 print 'Patch'
 print_traits()

Hi. Well, not sure anyone is interested in following up on the config 
file issue, but if so, attached is a complete version (sorry for the big 
size!). One class and two functions were moved from __init__.py, but 
besides that it's all new (and thus the non-patch). But at least my 
quick tests shows it to be backwards compatible (i.e. it can read the 
.matplotlibrc files, and rc(...) was rewritten to work with the new system).
A very quick synopsis:
config['text']['color'] = 'r'
config['text.color'] = 'g'
config['text.c'] = 'b'
rc('text', color=(100, 100, 100))
I believe the new syntax allows for easy addition of plugins. Several 
possible methods exist to handle this:
(1) allow a new file '.pylabrc' which will automatically be parsed as a 
python file. The function 'read_rc_file(...)' still allows old-style 
config files to be used inside the new method, but then we don't need to 
introduce new syntax for setting up plugins. If no '.pylabrc' file, 
process '.matplotlibrc' file old style.
(2) if '.matplotlibrc' is a directory, then assume new style. Each file 
in this directory will automatically be processed as a python file. If 
not a directory, process same as old method.
(3) Allow python code to be included in the .matplotlibrc file as:
#include <python-script>
Thus, instead of requiring new config-file syntax for configuration of 
the plugins, they can simply be put in python files.
Abe

John Hunter wrote:
> I just committed some changes to CVS for auto-log scaling of line
> plots - you pay a performance hit for log plots but it appears to
> work. Eg, you can do
> 
> x = arange(-2.002, 10, 0.01)
> y = sin(2*pi*x)
> plot(x,y)
> set(gca(), xscale='log')
> 
> and only the positive data are plotted. 
OK, with ssh CVS this works quite well. If you try the same with
 set(gca(), yscale='log')
you'll see a funky junction. I think here gnuplot can again give us some 
guidance for good bailout behaviour:
http://amath.colorado.edu/faculty/fperez/tmp/log-sin.ps
I think this is a reasonable approach.
Now, there is something funky though in semilogy:
In [13]: plot(frange(.1,1,npts=20),frange(0.1,1,npts=20))
Out[13]: [<matplotlib.lines.Line2D instance at 0x40f631ac>]
In [14]: set(gca(), yscale='log')
Out[14]: [None]
Works perfectly. Yet:
In [15]: close('all')
In [16]: semilogy(frange(.1,1,npts=20),frange(0.1,1,npts=20))
ERROR: min() or max() arg is an empty sequence
I'd expect these two to be identical, no? Perhaps you just haven't had the 
time to track down all the places where this needs to be applied.
At any rate, this is a huge improvement for log plots (which I happen to use 
every day). You've pretty much bought yourself the %run backend work, and at 
least a stab at the gtk stuff for ipython :)
Best,
f
ps. Now that I'm good with ssh CVS, let me know if you finish polishing this 
up, and I can test it quickly and report back. I have a ton of pretty 
stressful log plots I can throw at it.

John Hunter wrote:
>>>>>>"Fernando" == Fernando Perez <Fer...@co...> writes:
> 
> 
> Fernando> On second thought, I am starting to like the
> Fernando> mouse-proximity thingie: it allows you to point at a
> Fernando> specific axis and set only that one, which can be very
> Fernando> useful if you have a bunch of subplots and want to only
> Fernando> change one specific axis. This, which I imagine would
> Fernando> take some careful work at the command line, would be
> Fernando> trivial to do if you could just put your mouse pointer
> Fernando> over it and hit a key/button.
> 
> I think you misunderstand my question. mouse proximity is a given. I
> am referring to how to toggle log scale for the x and y axes
> separately with keybindings for the *axes under the mouse point*.
> 
> I am just as likely to want logx ans logy, which is why I wasn't
> assuming 'l'. But if gnuplot does the y axis with 'l', I'm happy to
> follow suit, but the question of the appropriate key for toggling the
> x scale is open.
Ah, gnuplot simply doesn't provide a separate x one. You get y with 'l', and 
if you want x, you mouse over it and do it. That's all they give you via 
hotkeys. You can always call the logscaling commands
set logscale x
I've found that solution to work well, but one person's everyday usage case is 
often someone else's weird corner case, so feel free to follow your own instincts.
Best,
f

>>>>> "Fernando" == Fernando Perez <Fer...@co...> writes:
 Fernando> On second thought, I am starting to like the
 Fernando> mouse-proximity thingie: it allows you to point at a
 Fernando> specific axis and set only that one, which can be very
 Fernando> useful if you have a bunch of subplots and want to only
 Fernando> change one specific axis. This, which I imagine would
 Fernando> take some careful work at the command line, would be
 Fernando> trivial to do if you could just put your mouse pointer
 Fernando> over it and hit a key/button.
I think you misunderstand my question. mouse proximity is a given. I
am referring to how to toggle log scale for the x and y axes
separately with keybindings for the *axes under the mouse point*.
I am just as likely to want logx ans logy, which is why I wasn't
assuming 'l'. But if gnuplot does the y axis with 'l', I'm happy to
follow suit, but the question of the appropriate key for toggling the
x scale is open.
JDH

Fernando Perez wrote:
>>I would like a key binding for toggling log/linear scale for x and y
>>independently. 'x' and 'y' are not good choices since they are
>>overloaded with constraining axes in interactive pan/zoom with the
>>toolbar. Suggestions? '1' and '2'? CTRL-x and and CTRL-y? 'l' and
>>'L'?
> 
> 
> I like 'l'/'L' for gnuplot consistency. Note that their implementation is a 
> bit funky though: 'l' toggles y-axis log (the most common case), while 'L' 
> toggles log on the axis closest to the mouse pointer. I'll leave it up to you 
> to decide whether you like this mouse-proximity thing or not. But 'l' for 
> y-log, which is probably the most common type of log plot, I think is nice.
On second thought, I am starting to like the mouse-proximity thingie: it 
allows you to point at a specific axis and set only that one, which can be 
very useful if you have a bunch of subplots and want to only change one 
specific axis. This, which I imagine would take some careful work at the 
command line, would be trivial to do if you could just put your mouse pointer 
over it and hit a key/button.
So now I'm +1 on following gnuplot's inspiration here.
As to which y-axis a plain 'l' should modify in the presence of subplots, I'm 
not sure. All? The first one? Is there a concept of 'active axis' in a plot 
with subplots? I simply don't know mpl enough to say anything useful here.
cheers,
f

John Hunter wrote:
> If you have data points really close to 0, eg 
> 
> 1 >>> x = arange(-2.00, 10, 0.01)
> 
> 2 >>> amin(abs(x))
> Out[2]: 4.163336342344337e-17
> 
> You may a heavy performance price because so many decades are plotted,
> each with minor ticks, and ticks are expensive in the current impl.
I had a look at gnuplot's strategy:
planck[~]> npy
In [1]: x = frange(1e-40, 10, npts=1003)
In [2]: gp('set logscale y')
In [3]: plot x,filename='logplotex.eps'
The result is here:
http://amath.colorado.edu/faculty/fperez/tmp/logplotex.eps
They seem to plot a maximum of 11 major ticks (that's what I'm guessing from a 
bunch of tests). When it fits, each major tick is a decade, but at some point 
their algorithm switches over (like in my example) to every 3rd, 5th, 
whatever-th decade, and the minor ticks become decade ticks themselves. When 
this happens, there are no logarithmically spaced ticks any more, obviously.
This is overall a nice approach, I think. I have quite a few plots which 
cover 30 decades, and in matplotlib the result looks very crowded, while 
gnuplot's enforcement of a max of 11 (or whatever) major ticks gives a clean 
looking plot.
Gnuplot has many problems (hence my switch -finally- to mpl), but it has over 
a decade of fine-tuning of its behavior and interface, so it's not a bad 
source of inspiration. It is mature and robust, and many of the things it 
does, it does really well. I'll keep bringing up areas where I feel we can 
benefit from it (I know it reasonably well) as I move all my code over to mpl.
Cheers,
f

>>>>> "Fernando" == Fernando Perez <Fer...@co...> writes:
 Fernando> Hmm. Is it possible that this hasn't propagated to
 Fernando> public CVS yet? I just updated, and this is what I get:
Highly probably - public CVS lags are getting better but are still
measurable
 backend_bases.py revision: 1.31
 lines.py revision: 1.14
 axes.py revision: 1.64

John Hunter wrote:
> I just committed some changes to CVS for auto-log scaling of line
> plots - you pay a performance hit for log plots but it appears to
> work. Eg, you can do
> 
> x = arange(-2.002, 10, 0.01)
> y = sin(2*pi*x)
> plot(x,y)
> set(gca(), xscale='log')
> 
> and only the positive data are plotted. 
Hmm. Is it possible that this hasn't propagated to public CVS yet? I just 
updated, and this is what I get:
planck[mwadap]> pylab
In [1]: x = arange(-2.002, 10, 0.01)
In [2]: y = sin(2*pi*x)
In [3]: plot(x,y)
Out[3]: [<matplotlib.lines.Line2D instance at 0x41041f0c>]
In [4]: set(gca(), xscale='log')
---------------------------------------------------------------------------
exceptions.ValueError Traceback (most recent 
call last)
/home/fperez/research/code/mwadap/<console>
/usr/lib/python2.3/site-packages/matplotlib/pylab.py in set(h, *args, **kwargs)
 1230 raise RuntimeError(msg)
 1231
-> 1232 draw_if_interactive()
 1233 return [x for x in flatten(ret)]
 1234
/usr/local/home/fperez/code/python/IPython/genutils.py in wrapper(*args, **kw)
/usr/lib/python2.3/site-packages/matplotlib/backends/__init__.py in 
draw_if_interactive()
 40 def draw_if_interactive():
 41 draw_if_interactive._called = True
---> 42 __draw_int()
 43 # Flag to store state, so external callers (like ipython) can 
keep track
 44 # of draw calls.
/usr/lib/python2.3/site-packages/matplotlib/backends/backend_tkagg.py in 
draw_if_interactive()
 56 figManager = Gcf.get_active()
 57 if figManager is not None:
---> 58 figManager.show()
 59
 60
/usr/lib/python2.3/site-packages/matplotlib/backends/backend_tkagg.py in 
show(self)
 276 # anim.py requires this
 277 if sys.platform=='win32' : self.window.update()
--> 278 else: self.canvas.draw()
 279 self._shown = True
 280
/usr/lib/python2.3/site-packages/matplotlib/backends/backend_tkagg.py in 
draw(self)
 141
 142 def draw(self):
--> 143 FigureCanvasAgg.draw(self)
 144 tkagg.blit(self._tkphoto, self.renderer._renderer, 2)
 145 self._master.update_idletasks()
/usr/lib/python2.3/site-packages/matplotlib/backends/backend_agg.py in draw(self)
 310 self.renderer = RendererAgg(w, h, self.figure.dpi)
 311 self._lastKey = key
--> 312 self.figure.draw(self.renderer)
 313
 314 def tostring_rgb(self):
/usr/lib/python2.3/site-packages/matplotlib/figure.py in draw(self, renderer)
 336
 337 # render the axes
--> 338 for a in self.axes: a.draw(renderer)
 339
 340 # render the figure text
/usr/lib/python2.3/site-packages/matplotlib/axes.py in draw(self, renderer)
 1480 if not self.get_visible(): return
 1481 renderer.open_group('axes')
-> 1482 self.transData.freeze() # eval the lazy objects
 1483 self.transAxes.freeze() # eval the lazy objects
 1484 if self.axison:
ValueError: Cannot take log of nonpositive value
Note that I'm running straight off the CVS directory, because the RPM 
rebuild/reinstall takes too long for permanent testing. What I did was just 
to manually copy the .so files back into the CVS dir, renamed 
/usr/lib/python2.3/site-packages/matplotlib to .ori, and made a symlink:
planck[site-packages]> d matplotlib
/usr/lib/python2.3/site-packages
lrwxrwxrwx 1 root 51 Feb 4 11:18 matplotlib -> 
/usr/local/installers/src/matplotlib/lib/matplotlib/
This seems to work OK (I checked with a few print statements that I am indeed 
running off the CVS matplotlib/ dir). Since the most recent CVS update 
doesn't seem to change any C++ code, this should be OK, no?
I'm seeing further weirdness with log plots. Try this:
semilogy(frange(.1,1,npts=20),frange(0.1,1,npts=20))
semilogy(frange(.1,1,npts=20),frange(0.0,1,npts=20))
semilogy(frange(.1,1,npts=20),frange(0.1,1,npts=20))
Not only does the second one crash, but then, the third line (identical to the 
first) also crashes. Something is left in an internally inconsistent state, 
and essentially all log plots become impossible afterwards. The only solution 
is to restart pylab altogether.
> If you have data points really close to 0, eg 
> 
> 1 >>> x = arange(-2.00, 10, 0.01)
> 
> 2 >>> amin(abs(x))
> Out[2]: 4.163336342344337e-17
> 
> You may a heavy performance price because so many decades are plotted,
> each with minor ticks, and ticks are expensive in the current impl.
> 
> I am also implementing some default keypress events on the pylab
> figure manager canvas. Eg 'g' to toggle grid mode.
> 
> I would like a key binding for toggling log/linear scale for x and y
> independently. 'x' and 'y' are not good choices since they are
> overloaded with constraining axes in interactive pan/zoom with the
> toolbar. Suggestions? '1' and '2'? CTRL-x and and CTRL-y? 'l' and
> 'L'?
I like 'l'/'L' for gnuplot consistency. Note that their implementation is a 
bit funky though: 'l' toggles y-axis log (the most common case), while 'L' 
toggles log on the axis closest to the mouse pointer. I'll leave it up to you 
to decide whether you like this mouse-proximity thing or not. But 'l' for 
y-log, which is probably the most common type of log plot, I think is nice.
> Are there other keybindings people would like to see implemented in
> the default pylab figures?
'r' for the ruler thingie?
Best,
f

I just committed some changes to CVS for auto-log scaling of line
plots - you pay a performance hit for log plots but it appears to
work. Eg, you can do
 x = arange(-2.002, 10, 0.01)
 y = sin(2*pi*x)
 plot(x,y)
 set(gca(), xscale='log')
and only the positive data are plotted. 
If you have data points really close to 0, eg 
 1 >>> x = arange(-2.00, 10, 0.01)
 2 >>> amin(abs(x))
 Out[2]: 4.163336342344337e-17
You may a heavy performance price because so many decades are plotted,
each with minor ticks, and ticks are expensive in the current impl.
I am also implementing some default keypress events on the pylab
figure manager canvas. Eg 'g' to toggle grid mode.
I would like a key binding for toggling log/linear scale for x and y
independently. 'x' and 'y' are not good choices since they are
overloaded with constraining axes in interactive pan/zoom with the
toolbar. Suggestions? '1' and '2'? CTRL-x and and CTRL-y? 'l' and
'L'?
Are there other keybindings people would like to see implemented in
the default pylab figures?
JDH
 

>>>>> "John" == John Hunter <jdh...@ac...> writes:
 John> The bad news is I don't know how and where the error crept
 John> in. I'll do some digging.
God Bless diff -- fixed in CVS. Make sure you have CVS revision of
legend.py 1.35 or later.
JDH

>>>>> "Fernando" == Fernando Perez <Fer...@co...> writes:
 Fernando> Hi all, I was just trying to make some plots with
 Fernando> legends in them, by following the damped exponential
 Fernando> example from pages 17-18 in the PDF user's guide. My
 Fernando> results are strange looking: the legend box size is
 Fernando> completely wrong, and the on-screen version has the
 Fernando> markers outside the box. The generated png does put the
 Fernando> markers in the right place, though. I'm using the TkAgg
 Fernando> backend, all in ipython-pylab. I've put up two pngs on
 Fernando> the net for reference:
Hey Fernando,
The good news is that matplotlib legends really do not look that big
and stupid -- this is a CVS bug (0.71 works), eg
http://matplotlib.sourceforge.net/screenshots.html#legend_demo
The bad news is I don't know how and where the error crept in. I'll
do some digging.
Thanks for letting me know!
JDH