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