matplotlib-users

[Matplotlib-users] show()

[Alan G I. <ai...@am...>]

We are warned to use show() at most once per script:
 http://matplotlib.sourceforge.net/faq.html#SHOW
For scripts I use in a classroom setting, I generally
need to call show() several times: once for each of
a sequence of figures.  I have been doing this with
the TKAgg backend, and I have had almost no problems.
A figure is shown, and the script does not continue
until I close the figure (by clicking its close button).
This is the behavior I want.

Is there another way I am supposed to be achieving this
behavior?  And can the warning be elaborated a bit, so
it is clearer why this is a bad idea?

Thank you,
Alan Isaac

Re: [Matplotlib-users] show()

[John H. <jdh...@ac...>]

>>>>> "Alan" == Alan G Isaac <ai...@am...> writes:

    Alan> Is there another way I am supposed to be achieving this
    Alan> behavior?  And can the warning be elaborated a bit, so it is
    Alan> clearer why this is a bad idea?

In truth, the latest release of matplotlib sets a flag on show to
prevent repeated calls from doing any real damage.

But for classroom use, I suggest you just put "interactive : True" in
your rc file and then you have no need for show.  Is there a downside
to this approach?

JDH

[Matplotlib-users] steps in plot()

[Peter G. <pgr...@ge...>]

Hi:

Want to inquire about gnuplot's 'steps' like functionality in 
matplotlib's plotting. A good example is show here:

http://chem.skku.ac.kr/~wkpark/tutor/gnuplot/gpdocs/steps.htm

In a most hack-ish way possible, for the sake of testing I tried this 
(modified simple_plot.py example):

--------------
#!/usr/bin/env python

from matplotlib.matlab import *

figure(1)
t = arange(0.0, 1.0, 0.01)
s = sin(2*2*pi*t)

t2=concatenate((t[1:], array([t[-1]])), 1)
s2=concatenate((array([s[0]]), s[:-1]), 1)

hlines(s, t, t2)
vlines(t, s, s2)

gca().autoscale_view()   #Using 60.2; need to call this for the the 
parts below y=0 to be visible

xlabel('time (s)')
ylabel('voltage (mV)')
title('About as simple as it gets, folks')'
grid(True)
#axis([0,1,-1,1])
savefig('simple_plot')

show()
-------------

It seems to work quite nicely, but I think an ideal way of doing this 
would be to incorporate it into the plot() command. Perhaps adding an 
option 'steps' (following gnuplot's convention could have steps equal 
'histeps', 'fsteps' or just  'steps' - see link above.. None could mean 
regular plot() behavior).  I would say this would be the most elegant 
option, but probably would call for John (or someone else from the core 
developers) to make the changes. Alternatively we could use above and 
wrap it in a plot_step() function.

Any interest in this? If so which way do we want to go?

Peter

Re: [Matplotlib-users] steps in plot()

[John H. <jdh...@ac...>]

>>>>> "Peter" == Peter Groszkowski <pgr...@ge...> writes:
    Peter> doing this would be to incorporate it into the plot()
    Peter> command. Perhaps adding an option 'steps' (following
    Peter> gnuplot's convention could have steps equal 'histeps',
    Peter> 'fsteps' or just 'steps' - see link above.. None could mean
    Peter> regular plot() behavior).  I would say this would be the
    Peter> most elegant option, but probably would call for John (or
    Peter> someone else from the core developers) to make the
    Peter> changes. Alternatively we could use above and wrap it in a
    Peter> plot_step() function.

    Peter> Any interest in this? If so which way do we want to go?

It might be easiest to make this a line style.  Then you could use the
builtin kwarg linestyle

  plot(x, y, linestyle='steps')

It shouldn't be too hard to modify lines.py to support this.  If you
want to take a stab at it, I'd be happy to include it.  The nice thing
about making it a line style is that the changes required would all be
contained to the lines.py file which is simple and clear.  If you
change how plot processes its arguments, it's easy to foul things up.

The only potential problem I see is this would prevent you from, for
example, having a dashed stepped line, since dash is itself a line
style.  But who needs a dashed stepped line, for heaven's sake?


JDH

Re: [Matplotlib-users] steps in plot()

[Peter G. <pgr...@ge...>]

John Hunter wrote:

>>>>>>"Peter" == Peter Groszkowski <pgr...@ge...> writes:
>>>>>>
>    Peter> doing this would be to incorporate it into the plot()
>    Peter> command. Perhaps adding an option 'steps' (following
>    Peter> gnuplot's convention could have steps equal 'histeps',
>    Peter> 'fsteps' or just 'steps' - see link above.. None could mean
>    Peter> regular plot() behavior).  I would say this would be the
>    Peter> most elegant option, but probably would call for John (or
>    Peter> someone else from the core developers) to make the
>    Peter> changes. Alternatively we could use above and wrap it in a
>    Peter> plot_step() function.
>
>    Peter> Any interest in this? If so which way do we want to go?
>
>It might be easiest to make this a line style.  Then you could use the
>builtin kwarg linestyle
>
>  plot(x, y, linestyle='steps')
>
>It shouldn't be too hard to modify lines.py to support this.  If you
>want to take a stab at it, I'd be happy to include it. 
>
Alrgith.. .this is my version of it.. just modifies lines.py (i'm using 
0.60.2 by the way).. :

    def _draw_steps(self, renderer, gc, xt, yt):
        siz=len(xt)
        if siz<2: return
        xt2=ones((2*siz,), xt.typecode())
        xt2[0:-1:2], xt2[1:-1:2], xt2[-1]=xt, xt[1:], xt[-1]
        yt2=ones((2*siz,), yt.typecode())
        yt2[0:-1:2], yt2[1::2]=yt, yt
        gc.set_linestyle('solid')
        gc.set_capstyle('projecting')
        renderer.draw_lines(gc, xt2, yt2)

also changed:

class Line2D(Artist):
    _lineStyles =  {
        '-'    : '_draw_solid',
        '--'   : '_draw_dashed',
        '-.'   : '_draw_dash_dot',
        ':'    : '_draw_dotted',
        'steps': '_draw_steps',
        'None' : '_draw_nothing'}
   
and:

lineStyles  = {'-':1, '--':1, '-.':1, ':':1, 'steps':1, 'None':1}

maybe a more memory friendly way to do this would be to loop through the 
arrays xt,yt and create extra points on the fly; then draw lines 
separately, but from my testing this current way seems (by far) the 
fastest.. im got lots of RAM and am in 'need for speed', so this works 
for me..


> The nice thing
>about making it a line style is that the changes required would all be
>contained to the lines.py file which is simple and clear.  If you
>change how plot processes its arguments, it's easy to foul things up.
>
>
yeah.. now that i know how things work a little better - i agree..

>The only potential problem I see is this would prevent you from, for
>example, having a dashed stepped line, since dash is itself a line
>style.  But who needs a dashed stepped line, for heaven's sake?
>
>
could always add.. 'steps--' if needed.. althought that's a little ugly!..

Re[2]: [Matplotlib-users] show()

[Alan G I. <ai...@am...>]

On Mon, 27 Sep 2004, John Hunter apparently wrote:
> But for classroom use, I suggest you just put "interactive
> : True" in your rc file and then you have no need for
> show.  Is there a downside to this approach?

I'm not sure.

There are two different classroom situations.

i. ad hoc drawing in the classroom from a Python shell.
Here setting interactive makes good sense, it seems.

ii. running prepared scripts for prepared graphical
illustrations.  Here I will usually have several
figures that I want displayed sequentially.
With interactive=False, this approach seems to work fine:
I close a figure and the next appears (TKAgg).
With interactive=True (and the show commands removed),
this approach seems to choke with an abnormal program termination:
Fatal Python Error: PyEval_RestoreThread: NULL tstate

Since I wish to do both, I decided I shd have
interactive:False
in my rc file.  Am I overlooking something?

Thanks,
Alan

Re: [Matplotlib-users] show()

[John H. <jdh...@ac...>]

>>>>> "Alan" == Alan G Isaac <ai...@am...> writes:


    Alan> ii. running prepared scripts for prepared graphical
    Alan> illustrations.  Here I will usually have several figures
    Alan> that I want displayed sequentially.  With interactive=False,
    Alan> this approach seems to work fine: I close a figure and the
    Alan> next appears (TKAgg).  With interactive=True (and the show
    Alan> commands removed), this approach seems to choke with an
    Alan> abnormal program termination: Fatal Python Error:
    Alan> PyEval_RestoreThread: NULL tstate

What environment / shell / OS are you running in?  

Could you send me an example script so I can try it?


    Alan> Since I wish to do both, I decided I shd have
    Alan> interactive:False in my rc file.  Am I overlooking
    Alan> something?

ipython is well suited to this task.  In the pylab mode, it sets
matplotlib to be in interactive mode in your backend of choice.  If
you want to run a matplotlib script from within the interactive
session, type

>>> run somescript.py

and it will transiently set interactive : False for the execution of
the script, and then restore your interactive setting.  So perhaps it
will give you the best of both interactive mode and script mode, under
one roof?

JDH