matplotlib-users Mailing List for matplotlib

Hello, I have a simple script that creates a few plots. Although the
script is in a while loop and creates plots endlessly, what I want is to
have one plot that is updated. How can I tell my script to update a
figure rather than create a new one? Thanks.
 
I'm using the WX backend. Thanks.
 
 

>>>>> "Carol" == Carol Leger <car...@sr...> writes:

    >> Yep, this is a bug.  In backend_ps in the the set_linedashes
    >> function on line 103, replace the line if seq: with if seq is
    >> not None and len(seq): My guess is you are using numarray, and
    >> if memory serves numarray but not Numeric fails on using an
    >> array as a boolean, which is what backend ps is doing here.
    >> 
    Carol> Yes, I am using numarray.  I made the change to line 103
    Carol> and now line 102 is reporting a similar error.

Ignore my last post - the solution I posted was as buggy as before.  I
think I finally nailed this down.  Basically, we are comparing seq1
and seq2, either are possibly None, or general sequences, or arrays.
I wrote a little function

def seq_allequal(seq1, seq2):
    """
    seq1 and seq2 are either None or sequences or numerix arrays
    Return True if both are None or both are seqs with identical
    elements
    """
    if seq1 is None:
        return seq2 is None

    if seq2 is None:
        return False
    #ok, neither are None:, assuming iterable
        
    if len(seq1) != len(seq2): return False
    return alltrue(equal(seq1, seq2))

You should import alltrue and equal from the numerix module at the top
of backend_ps, add this function to backend_ps and then replace
set_linedash with

    def set_linedash(self, offset, seq):        
        if self.linedash is not None:
            oldo, oldseq = self.linedash
            if seq_allequal(seq, oldseq): return
            
        if seq is not None and len(seq):
            s="[%s] %d setdash\n"%(_nums_to_str(*seq), offset)
            self._pswriter.write(s)
        else:
            self._pswriter.write("[] 0 setdash\n")
        self.linedash = (offset,seq)


I think this is finally coherent.  At least it passes my tests now...

JDH

>>>>> "Gregory" == Gregory Lielens <gre...@ff...> writes:

    Gregory> I though that calling draw() would update the active
    Gregory> figure without starting the mainloop already, or am I
    Gregory> confused? Alternatively, in the fltk backend, I have
    Gregory> allowed calling show() multiple times, it just check
    Gregory> before running the mainloop that it is not already
    Gregory> running...Maybe this is also feasible in a more general
    Gregory> way?

The matlab interface draw function does not need the renderer passed
as an arg (the FigureCanvas.draw method does) and it is intended for
interactive use when you want to force a redraw

  >>> o = title('blah')
  >>> o.set_fontsize(12)         # no draw
  >>> o.set_fontstyle('italic')  # no draw
  >>> draw()                     # draw

Perry and I discussed trying to come up with some python magic such
that calls to setattr on an artist would trigger a call to
the matlab interface draw_if_interactive.  This would have to be done
carefully, because some users will explicitly not want to force a
redraw on any call to a setter since drawing is potentially an
expensive operation.  True, they could temporarily turn interaction
off, but I think any solution here would need to be optional.

JDH

>>>>> "Carol" == Carol Leger <car...@sr...> writes:

    >> Yep, this is a bug.  In backend_ps in the the set_linedashes
    >> function on line 103, replace the line if seq: with if seq is
    >> not None and len(seq): My guess is you are using numarray, and
    >> if memory serves numarray but not Numeric fails on using an
    >> array as a boolean, which is what backend ps is doing here.
    >> 
    Carol> Yes, I am using numarray.  I made the change to line 103
    Carol> and now line 102 is reporting a similar error.

Sorry for all the troubles here.  Try this function for set_linedash
in backend_ps

    def set_linedash(self, offset, seq):        
        if self.linedash is not None:
            oldo, oldseq = self.linedash
            if offset==oldo and seq==oldseq: return        
            
        if seq is not None and len(seq):
            s="[%s] %d setdash\n"%(_nums_to_str(*seq), offset)
            self._pswriter.write(s)
        else:
            self._pswriter.write("[] 0 setdash\n")
        self.linedash = (offset,seq)

>>>>> "Humufr" == Humufr  <hu...@ya...> writes:


    Humufr> the bug:

    Humufr> I tried:

    Humufr> plot([1,2],[4,5],'g^',markersize=4,label='1')
    Humufr> errorbar([1,4],[6,7],[1,1],fmt='bh',markersize=4,label='4')
    Humufr> #plot([3,4],[6,7])
    Humufr> legend()
    Humufr> show()


    Humufr> and there are a problem with errorbar and the label and
    Humufr> the legend. Different line appeard and at the end we have
    Humufr> only the good symbols)

I don't consider this a bug but maybe you can convince me :-).  Legend
tries to be helpful but not omniscient.  If you have many lines and
only want to include some of them in the legend, just use the explicit
legend(lines, labels) form

    from matplotlib.matlab import *
    l1, = plot([1,2],[4,5],'g^',markersize=4)
    l2, errlines = errorbar([1,4],[6,7],[1,1],fmt='bh',markersize=4)

    plot([3,4],[6,7])

    legend((l1, l2), ('1', '4'))

    show()

Your suggestion that the legend ignore lines with empty labels appears
reasonable at first glance, but as Norbert will tell you, some people
use the fact that matplotlib legends include lines with empty labels
to their advantage when laying out legends.  

So in this case there is a way to get matplotlib to make the legend
you want, and if legend tries to get too smart about guessing what you
want it will get in the way of power users who don't what matplotlib
guessing what they are trying to do.

    Humufr> 2)

    Humufr> I add the line: plot([3,4],[6,7]) only to show you that
    Humufr> even if the plot command doesn't have a label the legend
    Humufr> give a place for it. I think at two solution to solve this
    Humufr> (perhaps it's already implemented and I didn't find...):

    Humufr> - by default if there are some label with the plot command
    Humufr> the plot command without are not take in count to create
    Humufr> the legend

    Humufr> - add something like: label=None to indicate the the user
    Humufr> don't want this line in the legend.

This could work.  Currently the default label is '', which as I said
is a perfectly legitimate label in some cases.  We could use None as a
hint to legend.  It would increase the coding burden somewhat, since
we'd always have to check for None before performing string ops on the
legend.  I'm amenable to this approach.  Anyone else have input here?

    Humufr> Thanks again to have found and correct all this bug so
    Humufr> fast, I'm very impressed :)

Thanks!
JDH

>>>>> "Norbert" == Norbert Nemec <Nor...@gm...> writes:

    Norbert> Hi there, apart from the "gry"-typo, the currect CVS-code
    Norbert> really is in a broken state after my patch was applied
    Norbert> and half-way reverted back. (The python2.2-pop problem)

    Norbert> Possible solutions:

    Norbert> * change "kwargs.get('xxx',def)" to
    Norbert> "popd(kwargs,'xxx',def)" and add popd to the import from
    Norbert> cbook

Here is what I committed to CVS earlier today in axes.Axes.legend

        if len(args)==0:
            labels = [line.get_label() for line in self.lines]
            lines = self.lines
            loc = popd(kwargs, 'loc', 1)

and more like it.  I think this works...

JDH

Hi there,

apart from the "gry"-typo, the currect CVS-code really is in a broken state 
after my patch was applied and half-way reverted back. (The python2.2-pop 
problem)

Possible solutions:

* change "kwargs.get('xxx',def)" to "popd(kwargs,'xxx',def)" and add popd to 
the import from cbook

* change "kwargs.get('xxx',def)" to "kwargs.pop('xxx',def)" (will not work for 
Python 2.2

* change the last lines of Axes.legend according to:
         lines = flatten(lines)
+        kwargs["loc"] = loc
+        self.legend_ = Legend(self, lines, labels, **kwargs)
-        self.legend_ = Legend(self, lines, labels, loc, **kwargs)
         return self.legend_

I guess, the first solution is, what will be done in the long run.

Ciao,
Nobbi




Am Mittwoch, 1. Dezember 2004 15:34 schrieb Humufr:
> Hi John,
>
> I tried:
>  > Yep, it's a bug.  Replace the indicate line from
>  > axes.py
>  >
>  >    loc = kwargs.gry('loc', 1)
>  >
>  > with
>  >
>  >    loc = kwargs.get('loc', 1)
>  >                 ^^^
>
> That correct the problem with legend() but I have another problem and I
> think it's another bug (not sure) it's not possible to tell to
> matplotlib in this case o use the "loc" keywords more it's impossible to
> use this keywords. There are always an error message:
>   File "<string>", line 3, in legend
>   File "/usr/lib/python2.3/site-packages/matplotlib/axes.py", line 1502,
> in legend
>     self.legend_ = Legend(self, lines, labels, loc, **kwargs)
> TypeError: __init__() got multiple values for keyword argument 'loc'
>
>
> example:
>
> plot ([2,3],[4,5])
> legend(('toto'),loc=2)
>
> I tried everything: loc='upper left', loc=0,1 , loc=(0,1), loc=2 etc.
> Nothing work but if I omit the " loc=  " . It's ok and that explain
> probably why I cant do something like:
>
> plot([1,2],[4,5],label='toto')
> legend(loc='upper left')
>
>
> Another strange thing I remark is:
>
> if you are doing:
>
> plot([1,2],[4,5])
> legend(('toto'))
>
> the text for the legend is vertical and not horizontal, that's work
> normally when we are using more than one argument.
>
> Thank you very much for you fast answer and sorry for the second
> question I had to verify more precisely in the archival.
>
>
> Nicolas
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

-- 
_________________________________________Norbert Nemec
         Bernhardstr. 2 ... D-93053 Regensburg
     Tel: 0941 - 2009638 ... Mobil: 0179 - 7475199
           eMail: <No...@Ne...>

       Hi John,

I just recuperate the cvs and I saw that you correct a lot of things 
inside the legend, thanks very much.

you will hate me soon I think :) but I found one bug and onething I 
don't like too much:


1)

the bug:

I tried:

plot([1,2],[4,5],'g^',markersize=4,label='1')
errorbar([1,4],[6,7],[1,1],fmt='bh',markersize=4,label='4')

#plot([3,4],[6,7])

legend()

show()


and there are a problem with errorbar and the label and the legend. 
Different line appeard and at the end we have only the good symbols)

2)

I add the line: plot([3,4],[6,7])  only to show you that even if the 
plot command doesn't have a label the legend give a place for it. I 
think at two solution to solve this (perhaps it's already implemented 
and I didn't find...):

- by default if there are some label with the plot command the plot 
command without are not take in count to create the legend

- add something like: label=None to indicate the the user don't want 
this line in the legend.

Thanks again to have found and correct all this bug so fast, I'm very 
impressed :)

Nicolas

HI all,

When I do:

from matplotlib.matlab import *

I get the following warning message:

Could not load matplotlib icon: Couldn't recognize the image file format 
for file '/usr/share/matplotlib/matplotlib.svg'

This is really just a minor annoyance, but it's been doing this for the 
last couple of releases. Anyone know why? why is it trying to load an svg?

Gentoo Linux Python 2.3.3, matplotlib 0.64, pygtk2.0 (I think)

-Chris




-- 
Christopher Barker, Ph.D.
Oceanographer
                                     		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

> Yep, this is a bug.  In backend_ps in the the set_linedashes function
> on line 103, replace the line
> 
>     if seq: 
> 
> with 
> 
>     if seq is not None and len(seq):
> 
> My guess is you are using numarray, and if memory serves numarray but
> not Numeric fails on using an array as a boolean, which is what
> backend ps is doing here.
> 
>
Yes, I am using numarray.  I made the change to line 103 and now line 
102 is reporting a similar error.

Traceback (most recent call last):
   File "testoverlay.py", line 91, in ?
     savefig('overlay.ps')
   File "/usr/lib/python2.3/site-packages/matplotlib/matlab.py", line 
1008, in savefig
     manager.canvas.print_figure(*args, **kwargs)
   File 
"/usr/lib/python2.3/site-packages/matplotlib/backends/backend_gtkagg.py", 
line 66, in print_figure
     agg.print_figure(filename, dpi, facecolor, edgecolor, orientation)
   File 
"/usr/lib/python2.3/site-packages/matplotlib/backends/backend_agg.py", 
line 385, in print_figure
     ps.print_figure(filename, dpi, facecolor, edgecolor, orientation)
   File 
"/usr/lib/python2.3/site-packages/matplotlib/backends/backend_ps.py", 
line 570, in print_figure
     self.figure.draw(renderer)
   File "/usr/lib/python2.3/site-packages/matplotlib/figure.py", line 
254, in draw
     for a in self.axes: a.draw(renderer)
   File "/usr/lib/python2.3/site-packages/matplotlib/axes.py", line 
3125, in draw
     l.draw(renderer)
   File "/usr/lib/python2.3/site-packages/matplotlib/lines.py", line 
257, in draw
     lineFunc(renderer, gc, xt, yt)
   File "/usr/lib/python2.3/site-packages/matplotlib/lines.py", line 
513, in _draw_dotted
     renderer.draw_lines(gc, xt, yt)
   File 
"/usr/lib/python2.3/site-packages/matplotlib/backends/backend_ps.py", 
line 275, in draw_lines
     self._draw_lines(gc,points[0:1000])
   File 
"/usr/lib/python2.3/site-packages/matplotlib/backends/backend_ps.py", 
line 264, in _draw_lines
     self._draw_ps("\n".join(ps), gc, None)
   File 
"/usr/lib/python2.3/site-packages/matplotlib/backends/backend_ps.py", 
line 375, in _draw_ps
     self.set_linedash(*gc.get_dashes())
   File 
"/usr/lib/python2.3/site-packages/matplotlib/backends/backend_ps.py", 
line 102, in set_linedash
     if (offset,seq) != self.linedash:
   File "/usr/lib/python2.3/site-packages/numarray/generic.py", line 
477, in __nonzero__
     raise RuntimeError("An array doesn't make sense as a truth value. 
Use sometrue(a) or alltrue(a).")
RuntimeError: An array doesn't make sense as a truth value.  Use 
sometrue(a) or alltrue(a).
-- 
Ms. Carol A. Leger
SRI International			Phone: (650) 859-4114
333 Ravenswood Avenue G-273
Menlo Park, CA 94025                    e-mail: le...@sr...

On Dec 1, 2004, at 10:07 AM, Alan G Isaac wrote:

> On Tue, 30 Nov 2004, Perry Greenfield apparently wrote:
>> 3) Tick control can be awkward if one simply wants to add an integral
>> number of minor ticks to the chosen major tick interval. Currently
>> using minor ticks forces one to access the plot objects, and specify
>> the major tick interval as well. It would be nice if one could just 
>> ask
>> for n minor ticks for each major tick interval by using the 
>> appropriate
>> keyword (name tbd). Some illustrations of possible alternatives:
>
>> plot(x, y, xmajor=5)
>> plot(x, y, xmajor=5, xminor=1)
>> plot(x, y, xminordiv=5) # 5 minor ticks per major
>
> The basic idea is very useful, but I think it is more common
> to specify the number of subdivisions rather than the number
> of tic marks.  (E.g., 'freq' in gnuplot or 'minordiv' in
> GAUSS.)  Maybe that's what you meant?  I do not know the
> Matlab convention.
>
Yes, you are right, I meant number of subdivisions.

On Tue, 30 Nov 2004, Perry Greenfield apparently wrote:
> 3) Tick control can be awkward if one simply wants to add an integral
> number of minor ticks to the chosen major tick interval. Currently
> using minor ticks forces one to access the plot objects, and specify
> the major tick interval as well. It would be nice if one could just ask
> for n minor ticks for each major tick interval by using the appropriate
> keyword (name tbd). Some illustrations of possible alternatives:

> plot(x, y, xmajor=5)
> plot(x, y, xmajor=5, xminor=1)
> plot(x, y, xminordiv=5) # 5 minor ticks per major

The basic idea is very useful, but I think it is more common
to specify the number of subdivisions rather than the number
of tic marks.  (E.g., 'freq' in gnuplot or 'minordiv' in
GAUSS.)  Maybe that's what you meant?  I do not know the
Matlab convention.

fwiw,
Alan Isaac

>>>>> "Jochen" == Jochen Voss <vo...@se...> writes:

    Jochen> Hello Nicolas
    Jochen> On Wed, Dec 01, 2004 at 09:34:51AM -0500, Humufr wrote:
    >> Another strange thing I remark is:
    >> 
    >> if you are doing:
    >> 
    >> plot([1,2],[4,5]) legend(('toto'))
    >> 
    >> the text for the legend is vertical and not horizontal, that's
    >> work normally when we are using more than one argument.
    Jochen> This happens because ('toto') is not a one-element list
    Jochen> but a string.  If you write

    Jochen>   plot([1,2],[4,5]) legend(('toto',))

    Jochen> instead it works as expected.

This is such a common mistake I think we should special case string
input for the labels and make it a len(1) tuple

   if is_string_like(labels): labels = (labels, )

All opposed, say nay!

JDH

Hello Nicolas

On Wed, Dec 01, 2004 at 09:34:51AM -0500, Humufr wrote:
> Another strange thing I remark is:
>=20
> if you are doing:
>=20
> plot([1,2],[4,5])
> legend(('toto'))
>=20
> the text for the legend is vertical and not horizontal, that's work=20
> normally when we are using more than one argument.
This happens because ('toto') is not a one-element list
but a string.  If you write

  plot([1,2],[4,5])
  legend(('toto',))

instead it works as expected.

I hope this helps,
Jochen
--=20
http://seehuhn.de/

Hi John,

I tried:


 > Yep, it's a bug.  Replace the indicate line from
 > axes.py
 >
 >    loc = kwargs.gry('loc', 1)
 >                
 > with
 >
 >    loc = kwargs.get('loc', 1)
 >                 ^^^

That correct the problem with legend() but I have another problem and I 
think it's another bug (not sure) it's not possible to tell to 
matplotlib in this case o use the "loc" keywords more it's impossible to 
use this keywords. There are always an error message:
  File "<string>", line 3, in legend
  File "/usr/lib/python2.3/site-packages/matplotlib/axes.py", line 1502, 
in legend
    self.legend_ = Legend(self, lines, labels, loc, **kwargs)
TypeError: __init__() got multiple values for keyword argument 'loc'


example:

plot ([2,3],[4,5])
legend(('toto'),loc=2)

I tried everything: loc='upper left', loc=0,1 , loc=(0,1), loc=2 etc. 
Nothing work but if I omit the " loc=  " . It's ok and that explain 
probably why I cant do something like:

plot([1,2],[4,5],label='toto')
legend(loc='upper left')


Another strange thing I remark is:

if you are doing:

plot([1,2],[4,5])
legend(('toto'))

the text for the legend is vertical and not horizontal, that's work 
normally when we are using more than one argument.

Thank you very much for you fast answer and sorry for the second 
question I had to verify more precisely in the archival.


Nicolas

Hi,

I am looking for a simple way to have a plot on which I can interact
with a cursor. An example:
- I have two plots on the same window and I wish to perform
  some action on these plots (change the scale, plot a different slice
  of an array, etc) depending on the pressed key and its location in the
  window. So if I am within the first plot, select the nearest point
  and redraw some info related to that point in the second plot (only
  when clicking with the left mouse button for example).

  If I type ''z'' (for zoom) then it is waiting for a second ''z''
  interpreted as the 2 corners of a rectangle and a zoom is made
  for this region of the plot.

I can do all this easily with ppgplot (pgplot module), but I failed
to write something simple with matplotlib.

So my questions:
- is there a simple way to do this? (interact with the cursor, 
mouse/keyboard
  and retrieve the location so further actions can be taken)

thanks a lot in advance

Eric Emsellem

> 1) Seems to me that repr for the plot objects could be blanked out for 
> interactive mode. Having python print out what it does now isn't 
> usually useful and in some cases (like error bars) leads to a dump on 
> the screen. Any reason not to make repr mode dependent (or at least 
> configurable)?
> 
> John pointed out that one of the worst offenders (error bars) actually 
> return lists of plot objects so it wouldn't do much good to override 
> repr for the plot objects unless one used a list object where repr was 
> overridden as well. The annoyance factor in interactive use is perhaps 
> sufficient to do this though. What do others think?

This has not really bothered me, but if this dissapear I will not be sad
either...so 0

> 2) Any support for being able to specify colors using more than single 
> character codes (say, using "red" or "green", and line styles and 
> symbols with more descriptive terms like "dashed". This is not in place 
> of the existing scheme, but as a more verbose alternative. Along those 
> lines, allowing something like:
> 
> plot(x1, y1, x2, y2, x3, y3, color=['red','green','blue'])

good idea, but I am well used to matlab shortcuts so +0

> 3) Tick control can be awkward if one simply wants to add an integral 
> number of minor ticks to the chosen major tick interval. Currently 
> using minor ticks forces one to access the plot objects, and specify 
> the major tick interval as well. It would be nice if one could just ask 
> for n minor ticks for each major tick interval by using the appropriate 
> keyword (name tbd). Some illustrations of possible alternatives:
> 
> plot(x, y, xmajor=5)
> plot(x, y, xmajor=5, xminor=1)
> plot(x, y, xminordiv=5) # 5 minor ticks per major regardless  of major 
> tick size
> 
> Generally, I expect that people set these interactively after plotting 
> without these options. When they see what is automatically produced, 
> this is a simple way of tweaking the plot without doing a lot of object 
> manipulation.

very good idea, +1: ticking adjustment is common before outputting a
figure for printing, and this will make this tinkering more easy...

> 4) The current means of doing overplotting is modal and confusing to 
> many used to IDL's approach. It is easy to forget what the current mode 
> is. IDL uses different commands (e.g., oplot vs plot) to overplot. Some 
> alternatives John and I mentioned:
> 
> a) generate 'o' versions of all plot functions (oplot, oimplot, etc.). 
> Easy to do but clutters the namespace.
> 
> b) have an 'over' function to apply to all such commands: over(plot, x, 
> y, color='g')
> 
> c) use a keyword argument to only apply to the function call:
> plot(x, y, hold=True) # doesn't change the hold state after completion, 
> but does overplot
> 
> I'm happy to have c) myself.

+1 for c), +0 for a) and -0 for b), I do not like the idea of having two
time the number of functions for this...if only because it will clutter
help(matplotlib.matlab) or dir(matplotlib.matlab) for example

> 5) For many customizations plot objects must be manipulated directly. 
> I'm wondering if this is a problem or not (I suspect that it is for a 
> reasonably large class of user). In particular I'm worried that the 
> leap to the object view is sufficiently high enough that many less
> sophisticated users will find that an off-putting hurdle. How does 
> matlab handle these sorts of customizations? The same way matplotlib 
> does? If so then I suppose my worries are unfounded. Keeping a lot of 
> the customization exposed within a purely functional interface means
> adding more functions or keywords which is its own problem. To be more 
> specific, how minor ticking is handled is a good example of making the 
> keyword interface richer and avoiding object manipulations for common 
> customizations:
> 
> plot(x, y, xminordiv=4)
> 
> vs
> 
> plot(x, y)
> ax = gca()
> ax.xaxis.set_major_locator(MultipleLocator(20))
> ax.xaxis.set_minor_locator(MultipleLocator(5))
> # update 
> The same could be said for specifying different kinds of tickers

many times matlab require to use an "object" approach with set/get for
advanced customization or for performance reason when doing dynamic
stuff...In general having to do the same in matplotlib is thus not a big
problem, provided that we have the "get" return all the settable
parameters, or that the python help work well for the same purpose. 
I think there has been new development that allow the get to work like
in matlab now, so this is great for me!

Avoiding object manipulation is a good idea for common stuff imho, like
for the proposed ticking control. In fact avoiding the object approach
for simple stuff is a strength of matlab I feel, because it allows for a
quick and dirty approach to plotting that is often enough, and then you
always have the possibility to dig into an object approach at any time
should you have the need for advanced customization/usages...
All of this for saying that the current approach suits me well, and that
I am +0/-0 on adding  non-object based alternative to replace something
that is feasable using object now. the +0/-0 is dependent on the
frequency, I am -0 doing this for something that is seldom used, but I
fear that "seldom" is dependent on applications/users, so it will not
always be easy to have everybody agree on what to add...

> 6) If one does these object manipulations the display is not updated. 
> One of John's list postings suggests resizing or calling the draw 
> method. The first is often unacceptable, and the second isn't quite so 
> obvious (since it requires specifying a renderer). Perhaps a simple 
> function to do the update that doesn't start a mainloop (as show does) 
> is needed. John responded:
> >
> > This is a problem.  I think the solution may be to override setattr in
> > the artist base class to call draw_if_interactive.  The matlab
> > interface could add this method at module load time so as to not break
> > the interface separation between the OO layer and the matlab layer.
> > I'll have to look into it.
> 
> (could it be as simple as defining update() to get the current renderer 
> and then call gcf().draw(currentrenderer)?)

I though that calling draw() would update the active figure without
starting the mainloop already, or am I confused? Alternatively, in the
fltk backend, I have allowed calling show() multiple times, it just
check before running the mainloop that it is not already running...Maybe
this is also feasible in a more general way?


Best regards,

Greg.

>>>>> "Jos=E9" =3D=3D Jos=E9 Alexandre Nalon <na...@te...> writes:

    Jos=E9> That, and setting the x_lim inverted, worked as I wanted,
    Jos=E9> thanks.

Great

    Jos=E9> But one more thing: while I was searching for a specific
    Jos=E9> command to do that, I found something (but not much) about
    Jos=E9> transforms, which I couldn't exactly understand what they do
    Jos=E9> and how they work, but they might be handy in the near
    Jos=E9> future. What are they exactly, and how can they help?

The official documentation is at
http://matplotlib.sf.net/matplotlib.transforms.html , but this may be
of limited help because it is not a tutorial.

matplotlib is divided conceptually into three parts: the "matlab
interface" which are the plot functions that most people use and see,
the object oriented "artists" which are classes that store the figure
information and the "backends" which actually put the ink on the paper.

The "artists" are things like lines, text, rectangles, images and so
on, and all of them are concrete classes derived from
matplotlib.artist.Artist.  Stupid name, I know, but I'm weak when it
comes to naming.  There are, at a minimum, two coordinate systems to
consider when you plot, the "world" coordinates, ie your data
coordinates, and the display coordinates, which are physical locations
on the display device.  The mapping between these two is given by a
transformation.

matplotlib transformations generally store the information about the
data coordinates and display coordinates, and possibly also a
nonlinear function (eg, polar, log).  Every artist stores it's own
transform, and you can place different artists in the figure using
different coordinate systems (transforms).

The vast majority of all plot commands use the default data->display
transform and this is invisible in normal usage.  But for convenience
and internal usage, matplotlib provides a couple of extra
transformations that you can make use of.  For example, suppose you
wanted to place a rectangle in the middle of the axes that was 25%
from the left, bottom, top and right.  You would place this rectangle
in the axes in what I refer to as axes coordinates, where 0 is the
left side of the axes, 1 is the width, 0.5 is the middle and so on.
This hypothetical rectangle has left, bottom=3D0.25, 0.25 and width,
height=3D0.5, 0.5

    from matplotlib.matlab import *
    from matplotlib.patches import Rectangle

    ax =3D subplot(111)
    plot([1,2,3])
    trans =3D ax.transAxes
    r =3D Rectangle( (0.25, 0.25), 0.5, 0.5, transform=3Dtrans)
    ax.add_patch(r)
    show()
   =20
Likewise, the figure instance provides a default transformation to
allow you to place objects in figure coordinates, where 0,0 is the
bottom left of the figure, 0.5, 0.5 is the middle and 1,1 is the upper
right. =20

Internally, I use this all the time.  For example, I may want to place
the x-ticklabels a few points under the bottom of the y location of
the x-axis, and I have a transformation that allows me to do this with
minimal coding overhead in the presence o figure resizing, dpi
changes, etc.

These are examples of the transformations that are provided by
default, and they tend to cover most of the things people want to do.
But if you want to do something more, you can use affine
transformation (matplotlib.transforms.Affine) or otherwise and set
this for a given artist to place the object into the figure as you
like it.

The example examples/alignment_test.py in the matplotlib src
distribution makes heavy use of placing text in axes coordinates, so
you may want to take a look at this for an example.

JDH

>>>>> "Jon" == Jon Peirce <Jon...@no...> writes:

    Jon> Actually, since it's the package that most users probably
    Jon> actually want, would it be more suitable to move
    Jon> matplotlib.matlab into matplotlib itself? Then we could
    Jon> simply

    Jon> import matplotlib

    Jon> Obviously that would mix the main user routines (plot()...)
    Jon> with the more administrative namespace (get_backend(),
    Jon> is_interactive()...) and maybe you'd want to move those into
    Jon> a separate (always imported) subpackage along the lines of
    Jon> matplotlib.res?

It is technically possible to reorganize the code to support this, but
it would break a lot of code in a nontrivial way.  While it is trivial
to search and replace instances of 'from matplotlib.matlab' with 'from
matplotlib.pylab' and so on, it would not be trivial to port scripts
that were using the matplotlib admin funcs after the kind of
reorganization this would entail.

But your post did give me an idea that might satisfy everyone and
provide the ease of use your idea suggests.  If we migrate
matplotlib.matlab to matplotlib.pylab as discussed, *and* add an
additional file pylab.py that resides in site-packages and is a one
liner

  from matplotlib.pylab import * 

then we preserve the easy conversion from old namespace to new
namespace while making it easy for script writers to do

  from pylab import *

Plea to distutils gurus: if you can figure out a way in the current
matplotlib setup.py setup to get a module named pylab.py into
site-packages, please advise!  The current module layout is somewhat
complicated and already stretches my distutils capabilities.

Of course if you were using Fernando's wonderful pylab feature in
ipython, it would be a trifle concern anyhow, since the import is done
automagically.

JDH

>>>>> "seberino" == seberino  <seb...@sp...> writes:

    seberino> I noticed when I pass the mouse pointer over a point on
    seberino> a graph that the (X, Y) values are displayed.  This is
    seberino> *great*.

Glad you like it.  Fernando Perez pushed me into getting this
implemented by repeatedly glowing about how nice this was in
gnuplot ...  No better way to get me to implement a feature than
favorably compare gnuplot to matplotlib :-)

    seberino> What if I wanted to customize/extend what gets printed
    seberino> in response to mouse pointer position?  Is this
    seberino> possible?

Yes, you can use the fmt_xdata and fmt_ydata attributes of the axes
instance to set a custom function.  If these are not set, matplotlib
will fall back on the default tick formatter -- these are explained at
http://matplotlib.sf.net/matplotlib.ticker.html .  See
examples/date_demo1.py for an example of setting your own coordinate
formatter functions with fmt_xdata and fmt_ydata.  The basic usage is

  def price(x): return '$%1.2f'%x
  ax.fmt_xdata = DateFormatter('%Y-%m-%d')
  ax.fmt_ydata = price

Here fmt_xdata is set to a callable instance (a DateFormatter
instance) and fmt_ydata is a plain old function that takes y as a
value and returns a string.

    seberino> e.g. If you had say 5 graphs on one plot, could you
    seberino> display all "Y values" for every X value??

    seberino> (X, Y1, Y2, Y3, Y4, Y5)??

This is a harder problem.  You need to capture the mouse location (see
examples/coords_demo.py) to get the x location and use this
information in your y formatter function .  Basically, you want to
ignore the actual value passed to your y format function and use the y
values of your time series at a given x index which you capture with a
mouse move event.

In the example below I use a class to store the x location and
communicate between the mouse position and the y format function.  The
variable self.ind is the index into the x, y1 and y2 vectors that is
closest to the mouse x position.  The example assumes your xdata are
monotonic, though you could do it for non-monotonic x with minor
modifications.

Note in principle the example below should work on all matplotlib
backends and os platforms.  In practice, with a little testing, I
found that this example reveals some bugs in matplotlib event handling
which we are looking into.  So for now, it appears to only work
properly on the GTK* backends (sigh), though it doesn't use any gtk
specific code.

from matplotlib.matlab import *

class MyFormatter:

    def __init__(self, x, y1, y2):
        self.x = x
        self.y1 = y1
        self.y2 = y2
        self.ind = None

    def on_move(self, event):
        'save the last x coord and get the index'
        if event.inaxes:
            # get the index into x closest to 
            self.ind = searchsorted(self.x, event.xdata)
        else:
            self.ind = None

    def fmty(self, y):
        'ignore y and format the value of y1 and y2 at ind'
        if self.ind is None: return  ''
        thisy1 = self.y1[self.ind]
        thisy2 = self.y2[self.ind]
        return '%1.2f, %1.2f'%(thisy1, thisy2)
    
        
t = arange(0, 2.0, 0.01)
s1 = sin(2*pi*t)
s2 = 2*sin(3*pi*t)

plot(t, s1, t, s2)

canvas = get_current_fig_manager().canvas
ax = gca()

o = MyFormatter(t, s1, s2)
canvas.mpl_connect('motion_notify_event', o.on_move)
ax.fmt_ydata = o.fmty

show()

>>>>> "Carol" == Carol Leger <car...@sr...> writes:

    Carol> I am trying to overlay a polar grid on a previously plotted
    Carol> axis.  The plot looks fine on the screen and in a png file.
    Carol> However, I get an error message when making a postscript
    Carol> file.

Yep, this is a bug.  In backend_ps in the the set_linedashes function
on line 103, replace the line

    if seq: 

with 

    if seq is not None and len(seq):

My guess is you are using numarray, and if memory serves numarray but
not Numeric fails on using an array as a boolean, which is what
backend ps is doing here.

Overlaying a polar plot over a rectangular axes.  Man, what will they
think of next!?  You will send me the screenshot when you're done,
right?

JDH

I am trying to overlay a polar grid on a previously plotted axis.

The plot looks fine on the screen and in a png file.  However, I get an 
error message when making a postscript file.


Basically, I drew one set of axes in rectangular coordinates and then 
tried to overlay a polar grid with:
	# Save current axes
	ax = gca()
	l, b, w, h = ax.get_position()	# Normalized
	axp = axes([l, b, w, h], polar=True, frameon=False)
	theta = arange(0,1,0.001) * 2*2*pi
	r = array([1.0 for i in range(len(theta))])
	polar(theta, r, color='k')
	angles = arange(0,360,45)
	labels = ('','NE','','NW','','SW', '','SE' '')
	thetalines, thetatext = thetagrids(angles, labels)
	# Restore previous axes
	axes(ax)

I am using a version of the CVS code that I downloaded today, Nov. 30, 
2004.  I have source code I could send, but I doubt you want an 
attachment sent to the list.

Here are the messages that appear:
   File "testoverlay.py", line 90, in ?
     savefig('overlay.ps')
   File "/usr/lib/python2.3/site-packages/matplotlib/matlab.py", line 
1008, in savefig
     manager.canvas.print_figure(*args, **kwargs)
   File 
"/usr/lib/python2.3/site-packages/matplotlib/backends/backend_gtkagg.py", 
line 66, in print_figure
     agg.print_figure(filename, dpi, facecolor, edgecolor, orientation)
   File 
"/usr/lib/python2.3/site-packages/matplotlib/backends/backend_agg.py", 
line 385, in print_figure
     ps.print_figure(filename, dpi, facecolor, edgecolor, orientation)
   File 
"/usr/lib/python2.3/site-packages/matplotlib/backends/backend_ps.py", 
line 570, in print_figure
     self.figure.draw(renderer)
   File "/usr/lib/python2.3/site-packages/matplotlib/figure.py", line 
254, in draw
     for a in self.axes: a.draw(renderer)
   File "/usr/lib/python2.3/site-packages/matplotlib/axes.py", line 
3125, in draw
     l.draw(renderer)
   File "/usr/lib/python2.3/site-packages/matplotlib/lines.py", line 
257, in draw
     lineFunc(renderer, gc, xt, yt)
   File "/usr/lib/python2.3/site-packages/matplotlib/lines.py", line 
513, in _draw_dotted
     renderer.draw_lines(gc, xt, yt)
   File 
"/usr/lib/python2.3/site-packages/matplotlib/backends/backend_ps.py", 
line 275, in draw_lines
     self._draw_lines(gc,points[0:1000])
   File 
"/usr/lib/python2.3/site-packages/matplotlib/backends/backend_ps.py", 
line 264, in _draw_lines
     self._draw_ps("\n".join(ps), gc, None)
   File 
"/usr/lib/python2.3/site-packages/matplotlib/backends/backend_ps.py", 
line 375, in _draw_ps
     self.set_linedash(*gc.get_dashes())
   File 
"/usr/lib/python2.3/site-packages/matplotlib/backends/backend_ps.py", 
line 103, in set_linedash
     if seq:
   File "/usr/lib/python2.3/site-packages/numarray/generic.py", line 
477, in __nonzero__
     raise RuntimeError("An array doesn't make sense as a truth value. 
Use sometrue(a) or alltrue(a).")
RuntimeError: An array doesn't make sense as a truth value.  Use 
sometrue(a) or alltrue(a).


-- 
Ms. Carol A. Leger
SRI International			Phone: (650) 859-4114
333 Ravenswood Avenue G-273
Menlo Park, CA 94025                    e-mail: le...@sr...