matplotlib-users — Discussion related to using matplotlib

[Matplotlib-users] How to get axes limits of subplot ?

[Axel K. <ko...@mo...>]

Hi,

I'm new to matplotlib and I have a question regarding axes.
Once I created some axes (either with the axes() command or with 
subplot() ), how can I later find out the limits (left bottom, width, 
height) of the axes ?
Maybe some trick with get() ?
Btw. is there somewhere a list of properties that I can get/set with 
get() or set() ?

    Many thanks,

                     Axel

Re: [Matplotlib-users] how to make matplotlib faster?

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

>>>>> "Ted" == Ted Drain <ted...@jp...> writes:

    Ted> At least where I work, our style guidelines make it a little
    Ted> more verbose.  I need to use descriptive variable names (for

The new short names were meant for easy, interactive use, to minimize
the number of keystrokes.  For scripts, especially if you have verbose
coding guidelines, I suggest you use the functions that are already
defined in the matplotlib __init__ file

  import matplotlib
  b = matplotlib.is_interactive()
  matplotlib.interactive(False)
  ....your plot commands here....
  matplotlib.interactive(b)

The short names call these functions, anyhow.

Note that this discussion may be moot, because when writing plotting
functions I rarely use the drawing commands of the pylab interface
since these are by and large wrappers of other methods, eg Axes
methods.  Since only the pylab plotting commands trigger the
draw_if_interactive method, you can safely do things like

  ax.plot([1,2,3])
  ax.set_xlabel('time')
  ax.set_title('this is a test')
  ax.grid(True)

w/o worrying about the interactive setting.

JDH

Re: [Matplotlib-users] how to make matplotlib faster?

[Ted D. <ted...@jp...>]

John,
There probably isn't a compulsive argument for either way of doing it.  The 
stack method is a very common graphics programming method for handling 
context switches, rotations, etc.  Most graphics systems use the idea of 
pushing and popping from a graphics context stack so you can do rotations 
and transformations inside a subroutine w/o messing up anything else.

At least where I work, our style guidelines make it a little more 
verbose.  I need to use descriptive variable names (for maintainability) 
and no one line if statements (which cause problems whenever you need to 
add debugging print or other statements).  Here's the difference between 
the methods with an additional option thrown in:

-------------
Option 1) push/pop

ipush()
try:
    [ ... plot ... ]
finally:
    ipop()

-------------
Option 2) flags

restoreInteractive = isinteractive()
ioff()
try:
    [ ... plot ... ]
finally:
    if restoreInteractive:
       ion()

-------------
Option 3) set/get method

interactiveOn = isinteractive()
ioff()
try:
    [ ... plot ... ]
finally:
    setinteractive( interactiveOn )

Ted

At 12:50 PM 12/13/2004, John Hunter wrote:
>Hi Ted,
>
>I hadn't thought of using a stack.  What is the argument for a stack
>as opposed to a single state manipulated along the lines of (with try
>except as needed)
>
>  b = isinteractive()
>  ioff()
>  ....your plot here...
>  if b: ion()
>
>Your approach requires one fewer line of code.  Are their other
>advantages to a stack approach?  I think a stack may be slightly less
>intuitive to a typical user, whereas turning drawing mode on and off
>is fairly straight forward.
>
>JDH
> >>>>> "Ted" == Ted Drain <ted...@jp...> writes:
>
>     Ted> John, I think the push/pop functions are going to be fairly
>     Ted> useful (ipush and ipop??).  We're going to be writing a lot
>     Ted> scripts (i.e. functions) that generate plots for our users.
>     Ted> There is no way to tell inside the script if it's going to be
>     Ted> used by a user in interactive mode or by another script (like
>     Ted> a batch report generator).  Having push/pop would let me do:
>
>     Ted> def stdPlot( [inputs] ): ipush( False ) try: [ create plot ]
>     Ted> finally: ipop()
>
>     Ted> Of course it's pretty easy to roll your own but I think it
>     Ted> would be nice to have it in the standard set of commands.
>
>
>
>-------------------------------------------------------
>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

[Matplotlib-users] ANN: IPython 0.6.5 is out.

[Fernando P. <Fer...@co...>]

Hi all,

[I'm taking the liberty to announce this here, as many scipy/matplotlib users 
are also ipython users, and this release includes changes coordinated with the 
new matplotlib release, coming very soon.  Sorry for those getting duplicates 
if you are on all these lists.]

I'm glad to announce the release of IPython 0.6.6.  IPython's homepage is at:

http://ipython.scipy.org

and downloads are at:

http://ipython.scipy.org/dist

I've provided RPMs (Py2.2 and 2.3), plus source downloads (.tar.gz and .zip).

Debian, Fink and BSD packages for this version should be coming soon, as the
respective maintainers (many thanks to Jack Moffit, Andrea Riciputi and Dryice
Liu) have the time to follow their packaging procedures.

Many thanks to Enthought for their continued hosting support for IPython, and
to all the users who contributed ideas, fixes and reports.


Release notes
-------------

This release was made to fix a few crashes recently found by users, and also
to keep compatibility with matplotlib, whose internal namespace structure was
recently changed.

* Adapt to matplotlib's new name convention, where the matlab-compatible
module is called pylab instead of matlab.  The change should be transparent to
all users, so ipython 0.6.6 will work both with existing matplotlib versions
(which use the matlab name) and the new versions (which will use pylab instead).

* Don't crash if pylab users have a non-threaded pygtk and they attempt to use
the GTK backends.  Instead, print a decent error message and suggest a few
alternatives.

* Improved printing of docstrings for classes and instances.  Now, class,
constructor and instance-specific docstrings are properly distinguished and
all printed.  This should provide better functionality for matplotlib.pylab
users, since matplotlib relies heavily on class/instance docstrings for
end-user information.

* New timing functionality added to %run.  '%run -t prog' will time the
execution of prog.py.  Not as fancy as python's timeit.py, but quick and easy
to use.  You can optionally ask for multiple runs.

* Improved (and faster) verbose exeptions, with proper reporting of dotted
variable names (this had been broken since ipython's beginnings).

* The IPython.genutils.timing() interface changed, now the repetition number
is not a parameter anymore, fixed to 1 (the most common case).  timings()
remains unchanged for multiple repetitions.

* Added ipalias() similar to ipmagic(), and simplified their interface.  They
now take a single string argument, identical to what you'd type at the ipython
command line.  These provide access to aliases and magics through a python
function call, for use in nested python code (the special alias/magic syntax
only works on single lines of input).

* Fix an obscure crash with recursively embedded ipythons at the command line.

* Other minor fixes and cleanups, both to code and documentation.


The NEWS file can be found at http://ipython.scipy.org/NEWS, and the full
ChangeLog at http://ipython.scipy.org/ChangeLog.


Enjoy, and as usual please report any problems.

Regards,

Fernando.

_______________________________________________
IPython-dev mailing list
IPy...@sc...
http://scipy.net/mailman/listinfo/ipython-dev

Re: [Matplotlib-users] how to make matplotlib faster?

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

>>>>> "Ted" == Ted Drain <ted...@jp...> writes:

    Ted> John, I think the push/pop functions are going to be fairly
    Ted> useful (ipush and ipop??).  We're going to be writing a lot
    Ted> scripts (i.e. functions) that generate plots for our users.
    Ted> There is no way to tell inside the script if it's going to be
    Ted> used by a user in interactive mode or by another script (like
    Ted> a batch report generator).  Having push/pop would let me do:

    Ted> def stdPlot( [inputs] ): ipush( False ) try: [ create plot ]
    Ted> finally: ipop()

    Ted> Of course it's pretty easy to roll your own but I think it
    Ted> would be nice to have it in the standard set of commands.

Hi Ted, 

I hadn't thought of using a stack.  What is the argument for a stack
as opposed to a single state manipulated along the lines of (with try
except as needed)

 b = isinteractive()
 ioff()
 ....your plot here...
 if b: ion()

Your approach requires one fewer line of code.  Are their other
advantages to a stack approach?  I think a stack may be slightly less
intuitive to a typical user, whereas turning drawing mode on and off
is fairly straight forward.

JDH

Re: [Matplotlib-users] how to make matplotlib faster?

[Perry G. <pe...@st...>]

On Dec 13, 2004, at 2:57 PM, Ted Drain wrote:

> John,
> I think the push/pop functions are going to be fairly useful (ipush 
> and ipop??).  We're going to be writing a lot scripts (i.e. functions) 
> that generate plots for our users.  There is no way to tell inside the 
> script if it's going to be used by a user in interactive mode or by 
> another script (like a batch report generator).  Having push/pop would 
> let me do:
>
> def stdPlot( [inputs] ):
>    ipush( False )
>    try:
>       [ create plot ]
>    finally:
>       ipop()
>
> Of course it's pretty easy to roll your own but I think it would be 
> nice to have it in the standard set of commands.
>

Yes, this was exactly the kind of usage I was envisioning. In other 
words,
I don't care what mode the user is using, I want this to run in 
"noninteractive"
mode (according to its current meaning), but I don't want to screw up 
their
state.

Perry

Re: [Matplotlib-users] how to make matplotlib faster?

[Ted D. <ted...@jp...>]

John,
I think the push/pop functions are going to be fairly useful (ipush and 
ipop??).  We're going to be writing a lot scripts (i.e. functions) that 
generate plots for our users.  There is no way to tell inside the script if 
it's going to be used by a user in interactive mode or by another script 
(like a batch report generator).  Having push/pop would let me do:

def stdPlot( [inputs] ):
    ipush( False )
    try:
       [ create plot ]
    finally:
       ipop()

Of course it's pretty easy to roll your own but I think it would be nice to 
have it in the standard set of commands.

At 05:54 AM 12/12/2004, John Hunter wrote:
> >>>>> "Perry" == Perry Greenfield <pe...@st...> writes:
>
>     Perry> In thinking about the ioff(), ion() approach it occurs to
>     Perry> me that it may not be quite so simple for scripts. I think
>     Perry> a common desire is for a script or function to turn off
>     Perry> interactive mode if it is on, but at the end, restore the
>     Perry> previous interactive state. In this case a push/pop
>     Perry> approach to interactive mode may be more appropriate rather
>     Perry> than stop/start. In particular, if interactive mode
>     Perry> happended to be off, you wouldn't want to turn it on at the
>     Perry> end of the script.
>
>BTW, Eric emailed me off list.  It appears that running his script in
>interactive mode was the root cause of his performance problems.
>
>In regards to running scripts from the python shell, I think the least
>invasive approach is to write a run function that stores the
>interactive state, calls ioff, runs the script with execfile, then
>calls ion (precisely what ipython does).  In fact, perhaps we should
>add a run function to the pylab interface which does just this.
>Fernando could simply override this function if he wants to do some
>additional ipython magic.  But this would wrap the logic for those who
>want to run scripts from the other python shell.  Of course it would
>only work for non-image backends and Tk, or GUI backends associated
>with a GUI shell like pycrust.
>
>I'm less worried about people inadvertently running scripts from the
>command shell with interactive set to True, because interactive
>defaults to False in rc and thus the person would have had to
>intentionally change it, at least at some point in dark history.
>Hence they are probably aware of it.  Singing the praises of ipython
>yet again, I leave the default in my rc to False, and run ipython when
>I want to work interactively, letting ipython turn interaction on for
>me. Thus I can run python somescript.py from the command shell assured
>that it is off, and still use matplotlib interactively w/o having to
>tweak the setting.
>
>But if there is some concern for users who would like to leave
>interactive on in rc (eg they like to use the standard python shell or
>some other shell) and still be able to get the efficiency when running
>scripts from the command shell, it might be possible to inspect
>whether we are in a running in a python shell, and plug this
>additional information into draw_if_interactive.  Something like
>
>def draw_if_interactive():
>     if running_in_python_shell() and matplotlib.is_interactive():
>        canvas.draw()
>
>Anyone know how to determine whether you are running code in a python
>shell versus running a script, eg from a command shell?
>
>It occurs to me that "interactive" is not really the best name for
>this matplotlib state.  Really we want something that conveys
>"draw_after_every_plot_command".  When I named it, I was assuming that
>when working interactively you would want to update with every plot
>command, but have learned that this is not always the case.  Do you
>think it's worth coming up with new names (isdraw(),
>draw_always(True/False), etc, while preserving the old names for a
>while with deprecation)?  Because that's what we're really doing,
>controlling the drawing.
>
>JDH
>
>
>
>
>
>-------------------------------------------------------
>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

Ted Drain     Jet Propulsion Laboratory   ted...@jp...    

Re: [Matplotlib-users] Date demos from examples fail to run

[Delbert D. F. <iq...@so...>]

On Thursday 09 December 2004 03:22 pm, John Hunter wrote:
> >>>>> "Delbert" == Delbert D Franz <iq...@so...> writes:
> 
>     Delbert> After downloading and installing these two packages all
>     Delbert> but date_demo_rrule.py completed properly.  The error in
>     Delbert> this case was an unknown name "rand".  A check of the
>     Delbert> Python Library reference stated it was obsolete.  I
>     Delbert> replaced it with random.randrange but got another error,
>     Delbert> an assertion error apparently on the y value.  Being
>     Delbert> somewhat new to Python and even newer to matplotlib I
>     Delbert> gave up on that demo.
> 
>     Delbert> Perhaps someone else can test date_demo_rrule.py and see
>     Delbert> what happens.  It is always a good thing when demos in
>     Delbert> fact run!
> 
> True!  But all of these demos do run for me.  I suggest you flush your
> existing matplotlib by removing site-packages/matplotlib and your
> "build" directory and reinstall from the official source at
> http://sourceforge.net/project/showfiles.php?group_id=80706&package_id=82474&release_id=281218.
> Please follow the instructions at
> http://matplotlib.sourceforge.net/installing.html, eg make sure you
> have numeric or numarray installed when you compile matplotlib.
> 

After a bit of pondering and  one false start (one compile failed because
it could not find some item related to GTK) I got matplotlib compiled for
the Tkinter backend only.  It is the only one I'm interested in right now
anyway.  

An update to the .matplotlibrc file solved the problem of seeking the GTKAgg 
backend which was not there and we were off to the races.  All of the date
examples completed without a hitch.  A quite gratifying result!  Apparently 
the Debian package I downloaded had some problems.

One of the biggest challenges was translating short forms of software names
into the package names used on the Debian package site-just one of those
realities of the great world of open-source software.  Not everyone uses
the same descriptive name for the same entity. 

> Let us know if you have more troubles, and please include a full
> traceback from one of the date demos and run it with
> 
> > python date_demo1.py --verbose-helpful
> 
> and report the output.
> 
> 
>     Delbert> I am also testing under MS Windows and the dateutils and
>     Delbert> pytz files came with that install but none of the example
>     Delbert> files came.  Not sure why they are not included in the
>     Delbert> *.exe installer.
> 
> It's a distutils thing.  Suggestions here welcome.
> 
> JDH
> 
> 
> -------------------------------------------------------
> 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
> 
> 

Re: [Matplotlib-users] How adjust colors for color plots to different ranges?

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

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

    seberino> I'm using pcolor.  All z values looked the same color.
    seberino> It may be a my fault (my bug) if you say colors should
    seberino> be different.  I'll try your customizations too.

    seberino> Does clim work with pcolor?

There may be a problem with colormapping/clim in 0.64, but these are
all fixed in the next release of matplotlib, due out today.  I just
tested

    1 >>> Z = rand(10,10)*20000 + 40000

    2 >>> pcolor(Z)
    Out[2]: <matplotlib.collections.PolyCollection instance at 0x41d3cf4c>

    3 >>> colorbar
    ----> colorbar()
    Out[3]: <matplotlib.axes.Axes instance at 0x41d3624c>


    4 >>> clim(30000,80000)

and everything worked as expected.

JDH

Re: [Matplotlib-users] How adjust colors for color plots to different ranges?

[<seb...@sp...>]

I'm using pcolor.  All z values looked the same color.  It may
be a my fault (my bug) if you say colors should be different.
I'll try your customizations too.

Does clim work with pcolor?

CS

On Mon, Dec 13, 2004 at 09:23:51AM -0600, John Hunter wrote:
> >>>>> "seberino" == seberino  <seb...@sp...> writes:
>
>     seberino> The z-axis values that I want to denote with color on
>     seberino> this plot range from something like 57000 to 66000.
>
>     seberino> I think I somehow need to tell Matplotlib what these
>     seberino> minimum and maximum values are so that my color spectrum
>     seberino> can range over desired colors for my specific plotting
>     seberino> range.
>
>     seberino> How do this?  (How make 57000 be one color extreme and
>     seberino> make 66000 be my other color extreme?)
>
> What plotting function are you using, imshow, pcolor, scatter, etc?
> The matplotlib color mapping and scaling will handle this
> automatically.  It assigns 57000 to the first color on your colormap
> and 66000 to the last color, with interpolation between.  There are a
> variety of ways to customize this
>
>   # vmin is 57000 but vmax is changed
>   >>> imshow(X, vmax=70000)
>
>   # vmin is 66000 but vmin is changed
>   >>> imshow(X, vmin=50000)
>
>
>   # vmin and vmax both customized
>   >>> imshow(X, vmax=50000, vmax=70000)
>
> Once you've plotted your data, you can use the clim function to set
> the color limits
>
>   >>> clim(55000, 60000)
>
> Should help,
> JDH
>

--
_______________________________________

Christian Seberino, Ph.D.
SPAWAR Systems Center San Diego
Code 2872
49258 Mills Street, Room 158
San Diego, CA 92152-5385
U.S.A.

Phone: (619) 553-9973
Fax  : (619) 553-6521
Email: seb...@sp...
_______________________________________

Re: [Matplotlib-users] How adjust colors for color plots to different ranges?

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

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

    seberino> The z-axis values that I want to denote with color on
    seberino> this plot range from something like 57000 to 66000.

    seberino> I think I somehow need to tell Matplotlib what these
    seberino> minimum and maximum values are so that my color spectrum
    seberino> can range over desired colors for my specific plotting
    seberino> range.

    seberino> How do this?  (How make 57000 be one color extreme and
    seberino> make 66000 be my other color extreme?)

What plotting function are you using, imshow, pcolor, scatter, etc?
The matplotlib color mapping and scaling will handle this
automatically.  It assigns 57000 to the first color on your colormap
and 66000 to the last color, with interpolation between.  There are a
variety of ways to customize this

  # vmin is 57000 but vmax is changed
  >>> imshow(X, vmax=70000)

  # vmin is 66000 but vmin is changed
  >>> imshow(X, vmin=50000)


  # vmin and vmax both customized
  >>> imshow(X, vmax=50000, vmax=70000)

Once you've plotted your data, you can use the clim function to set
the color limits

  >>> clim(55000, 60000)

Should help,
JDH

Re: [Matplotlib-users] How adjust colors for color plots to different ranges?

[Steve C. <ste...@ya...>]

On Sun, 2004-12-12 at 22:14 -0800, seb...@sp... wrote:
> The z-axis values that I want to denote with color on this
> plot range from something like 57000 to 66000.
> 
> I think I somehow need to tell Matplotlib what these minimum
> and maximum values are so that my color spectrum can range over
> desired colors for my specific plotting range.
> 
> How do this?  (How make 57000 be one color extreme and make
> 66000 be my other color extreme?)
> 
> Chris
By normalising 57000 to 0 and 66000 to 1 and using a custom colormap
function to generate rgb values to feed into matplotlib.
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/52273
I was looking at this cookbook recipe yesterday, it looks like it does
what you require.

Steve

Re[2]: [Matplotlib-users] using show() multiple times: no longer

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

On Sun, 12 Dec 2004, John Hunter apparently wrote:
> We've taken pains to protect against multiple calls to show.  If you
> can provide a script which replicates the problem.  Please test
> against the latest matplotlib, preferably the next release, due out
> tomorrow barring the unexpected (which is never expected).

Will do.

Thank you,
Alan Isaac

Re[2]: [Matplotlib-users] using show() multiple times: no longer

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

>> Somewhat related: can I control the order in which figures
>> are displayed when the show() command is given, or will the
>> highest numbered figure always display on top?


On Sun, 12 Dec 2004, John Hunter apparently wrote:
> This may be backend dependent, I haven't tested it.  But if it is the
> highest figure on top you should be in good shape, right?, because you
> can provide the figure numbers in the order you want the figures
> to appear, bottom to top.

i. This is not a huge deal, as it seems to be manageable
just as you say.
ii. However, as I add to a script to illustrate more
issues, which should come later in a presentation,
this implies renumbering all the figures.  Not ideal.
iii.  So it seems the opposite of the current convention 
would be an improvement: show figure 1 last, so that it
is "on top" in a presentation.  This would be my first
preference.
iv. Or, could show take an argument---a tuple of
numbers determining the order for the figures to appear.
This would be my 2nd preference.

fwiw,
Alan Isaac

[Matplotlib-users] How adjust colors for color plots to different ranges?

[<seb...@sp...>]

The z-axis values that I want to denote with color on this
plot range from something like 57000 to 66000.

I think I somehow need to tell Matplotlib what these minimum
and maximum values are so that my color spectrum can range over
desired colors for my specific plotting range.

How do this?  (How make 57000 be one color extreme and make
66000 be my other color extreme?)

Chris
--
_______________________________________

Christian Seberino, Ph.D.
SPAWAR Systems Center San Diego
Code 2872
49258 Mills Street, Room 158
San Diego, CA 92152-5385
U.S.A.

Phone: (619) 553-9973
Fax  : (619) 553-6521
Email: seb...@sp...
_______________________________________

Re: [Matplotlib-users] using show() multiple times: no longer

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

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

    Alan> Aside from my wishes, should the script fail in this fashion
    Alan> (rather than being more gracefully rejected)?  I realize we
    Alan> have been warned against using show() multiple times ...

We've taken pains to protect against multiple calls to show.  If you
can provide a script which replicates the problem.  Please test
against the latest matplotlib, preferably the next release, due out
tomorrow barring the unexpected (which is never expected).

    Alan> Somewhat related: can I control the order in which figures
    Alan> are displayed when the show() command is given, or will the
    Alan> highest numbered figure always display on top?

This may be backend dependent, I haven't tested it.  But if it is the
highest figure on top you should be in good shape, right?, because you
can provide the figure numbers in the order you want the figures
to appear, bottom to top.

JDH

Re: [Matplotlib-users] figure: facecolor not respected (Agg backend) ?

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

>>>>> "Uwe" == Uwe Hoffmann <qu...@ti...> writes:

    Uwe> Hi, i am using the simple_plot.py example with the Agg or
    Uwe> WXAgg backends.  If i insert the following line:
    Uwe> rcParams["figure.facecolor"] = "r" the background is red when
    Uwe> using the WXAgg driver but with the Agg backend the
    Uwe> background of the png image is still white.

    Uwe> Any hints ?  (matplotlib 0.64, linux)

help(savefig)

The default figure facecolor is passed as a kwarg in savefig.  The
idea is that you often want a different background color for the
figure in a GUI (eg gray) and in hardcopy (eg white)

  savefig('myfile', facecolor='r') 

should work.

JDH

[Matplotlib-users] figure: facecolor not respected (Agg backend) ?

[Uwe H. <qu...@ti...>]

Hi,

i am  using the simple_plot.py example with the Agg or WXAgg backends.
If i insert the following line:
rcParams["figure.facecolor"] = "r"
the background is red when using the WXAgg driver but with the Agg 
backend the background of the png image is still white.

Any hints ?
(matplotlib 0.64, linux)

greetings
	Uwe

Re: [Matplotlib-users] how to make matplotlib faster?

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

>>>>> "Perry" == Perry Greenfield <pe...@st...> writes:

    Perry> In thinking about the ioff(), ion() approach it occurs to
    Perry> me that it may not be quite so simple for scripts. I think
    Perry> a common desire is for a script or function to turn off
    Perry> interactive mode if it is on, but at the end, restore the
    Perry> previous interactive state. In this case a push/pop
    Perry> approach to interactive mode may be more appropriate rather
    Perry> than stop/start. In particular, if interactive mode
    Perry> happended to be off, you wouldn't want to turn it on at the
    Perry> end of the script.

BTW, Eric emailed me off list.  It appears that running his script in
interactive mode was the root cause of his performance problems.

In regards to running scripts from the python shell, I think the least
invasive approach is to write a run function that stores the
interactive state, calls ioff, runs the script with execfile, then
calls ion (precisely what ipython does).  In fact, perhaps we should
add a run function to the pylab interface which does just this.
Fernando could simply override this function if he wants to do some
additional ipython magic.  But this would wrap the logic for those who
want to run scripts from the other python shell.  Of course it would
only work for non-image backends and Tk, or GUI backends associated
with a GUI shell like pycrust.

I'm less worried about people inadvertently running scripts from the
command shell with interactive set to True, because interactive
defaults to False in rc and thus the person would have had to
intentionally change it, at least at some point in dark history.
Hence they are probably aware of it.  Singing the praises of ipython
yet again, I leave the default in my rc to False, and run ipython when
I want to work interactively, letting ipython turn interaction on for
me. Thus I can run python somescript.py from the command shell assured
that it is off, and still use matplotlib interactively w/o having to
tweak the setting.  

But if there is some concern for users who would like to leave
interactive on in rc (eg they like to use the standard python shell or
some other shell) and still be able to get the efficiency when running
scripts from the command shell, it might be possible to inspect
whether we are in a running in a python shell, and plug this
additional information into draw_if_interactive.  Something like

def draw_if_interactive():
    if running_in_python_shell() and matplotlib.is_interactive():
       canvas.draw()

Anyone know how to determine whether you are running code in a python
shell versus running a script, eg from a command shell?

It occurs to me that "interactive" is not really the best name for
this matplotlib state.  Really we want something that conveys
"draw_after_every_plot_command".  When I named it, I was assuming that
when working interactively you would want to update with every plot
command, but have learned that this is not always the case.  Do you
think it's worth coming up with new names (isdraw(),
draw_always(True/False), etc, while preserving the old names for a
while with deprecation)?  Because that's what we're really doing,
controlling the drawing.

JDH

RE: [Matplotlib-users] how to make matplotlib faster?

[Perry G. <pe...@st...>]

In thinking about the ioff(), ion() approach it occurs to me that
it may not be quite so simple for scripts. I think a common 
desire is for a script or function to turn off interactive mode
if it is on, but at the end, restore the previous interactive 
state. In this case a push/pop approach to interactive mode may
be more appropriate rather than stop/start. In particular, if 
interactive mode happended to be off, you wouldn't want to turn
it on at the end of the script.

Perry

RE: [Matplotlib-users] how to make matplotlib faster?

[Perry G. <pe...@st...>]

John Hunter wrote:
[...]
> 
> By default, matplotlib defers drawing until the end of the script
> because drawing can be an expensive opertation, and you may not
> want to update the plot every time a single property is changed, only
> once after all the properties have changed.
> 
> But in interactive mode, eg from the python shell, you usually do want
> to update the plot with every command, eg, after changing the xlabel
> or the marker style of a line.  With the TkAgg backend, you can use
> matplotlib from an arbitrary python shell.  Just set TkAgg to be your
> default backend and interactive to be True in your matplotlibrc file
> and fire up python.  Then
> 
> >>> from pylab import *
> >>> plot([1,2,3])
> >>> xlabel('hi mom')
> 
> should work out of the box.  Note, in batch mode, ie when making
> figures from scripts, interactive mode can be slow since it redraws
> the figure with each command.  So you may want to think carefully
> before making this the default behavior.  TkAgg sets interactive mode
> to True when you issue the show command.
> 
[...]

I'd just add that we may want to recommend that using ioff(), ion()
be part of the matplotlib idiom for writing demos and larger, more
involved plotting programs and scripts particularly where the 
author of the script or function is unsure of what context it
will be run in. That way it always runs efficiently. Does that
seem a reasonable thing to recommend?

Perry

Re: [Matplotlib-users] how to make matplotlib faster?

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

>>>>> "Perry" == Perry Greenfield <pe...@st...> writes:

    Perry> John Hunter Wrote:>
    >> Aside from the aforementioned "run" mode of ipython, which does
    >> just this, the basic incantation is
    >> 
    >> >>> from matplotlib import interactive, is_interactive >>> b =
    >> is_interactive() # store the current interactive state >>>
    >> plot(blah, blah) # make some plots >>> interactive(False) #
    >> turn interactive off >>> for i in arange(1e4096):
    >> plot(arange(i), arange(i)**2) # don't try this at home >>>
    >> interactive(b) # restore previous interactive state
    >> 
    >> Basically, this is what ipython does.  This is wrapped into a
    >> single function "run", called like
    >> 
    >> >>> x = 1 # some fluff >>> run ~/myexamples/simple_demo.py #
    >> turn interactive off for run >>> x = 2 # interactive setting is
    >> restored
    >> 
    >> But of course, you can use the interactive / is_interactive
    >> functions in any script or interactive session.
    >> 
    >> To make this more accessible, perhaps we should add an
    >> interactive (or update) kwarg to plot and friends, in the same
    >> vein that we discussed a kwarg for hold, so you can easily do
    >> things like
    >> 
    >> plot(x, y, hold=False) # add plot, clearing previous plot(x, y,
    >> update=False) # add plot but do not update
    >> 
    >> But the question arises, does the additional complexity in the
    >> matplotlib internals required to support this justify the
    >> savings for the occasional user who would otherwise have to
    >> type a couple of extra lines?
    >> 
    Perry> In this case I don't think so. the function interactive()
    Perry> is what I was looking for, not a keyword argument. Unlike
    Perry> overplotting, I think interactive() is likely to be used
    Perry> almost entirely in scripts and functions and that is by far
    Perry> the better approach.  So it's already good enough as far as
    Perry> I'm concerned.

Following these discussions, I just added ion and ioff to the pylab
interface, and updated the web site interaction page with (not
uploaded yet) with the following.  Let me know if you have anything to
add here.

By default, matplotlib defers drawing until the end of the script
because drawing can be an expensive opertation, and you may not
want to update the plot every time a single property is changed, only
once after all the properties have changed.

But in interactive mode, eg from the python shell, you usually do want
to update the plot with every command, eg, after changing the xlabel
or the marker style of a line.  With the TkAgg backend, you can use
matplotlib from an arbitrary python shell.  Just set TkAgg to be your
default backend and interactive to be True in your matplotlibrc file
and fire up python.  Then

>>> from pylab import *
>>> plot([1,2,3])
>>> xlabel('hi mom')

should work out of the box.  Note, in batch mode, ie when making
figures from scripts, interactive mode can be slow since it redraws
the figure with each command.  So you may want to think carefully
before making this the default behavior.  TkAgg sets interactive mode
to True when you issue the show command.

Unfortunately, due to the 'mainloop' cycle of GUI toolkits, it is not
yet possible to use matplotlib from an arbitrary python shell with the
other GUI backends.  You must use a custom python shell that runs the
GUI is a separate thread.

The recommended way to use matplotlib interactively from a shell is
with ipython, which has an pylab mode that detects your matplotlib
.matplotlibrc file and makes the right settings to run matplotlib with
your GUI of choice in interactive mode using threading.  gtk users
will need to make sure that they have compiled gtk with threading for
this to work.  Using ipython in pylab mode is basically a nobrainer
because it knows enough about matplotlib internals to make all the
right settings for you internally

  peds-pc311:~> ipython -pylab
  Python 2.3.3 (#2, Apr 13 2004, 17:41:29) 
  Type "copyright", "credits" or "license" for more information.

  IPython 0.6.5 -- An enhanced Interactive Python.
  ?       -> Introduction to IPython's features.
  %magic  -> Information about IPython's 'magic' % functions.
  help    -> Python's own help system.
  object? -> Details about 'object'. ?object also works, ?? prints more.

  Welcome to pylab, a matplotlib-based Python environment.
    help(matplotlib) -> generic matplotlib information.
    help(matlab)     -> matlab-compatible commands from matplotlib.
    help(plotting)   -> plotting commands.

  >>> plot( rand(20), rand(20), 'go' )

Note that you did not need to import any matplotlib names because in
pylab mode ipython will import them for you.  ipython turns on
interactive mode for you, and also provides a "run" command so you can
run matplotlib scripts from the matplotlib shell and then
interactively update your figure.  ipython will turn off interactive
mode during a run command for efficiency, and then restore the
interactive state at the end of the run.

  >>> cd python/projects/matplotlib/examples/
  /home/jdhunter/python/projects/matplotlib/examples
  >>> run simple_plot.py
  >>> title('a new title', color='r')

The pylab interface provides 4 commands that are useful for
interactive control.  Note again that the interactgive setting
primarily controls whether the figure is redrawn with each plotting
command.  is_interactive returns the interactive setting, ion turns
interactive on, ioff turns it off, and draw forces a redraw of the
entire figure.  Thus when working with a big figure in which drawing
is expensive, you may want to turn matplotlib's interactive setting
off temporarily to avoid the performance hit

  >>> run mybigfatfigure.py
  >>> ioff()      # turn updates off
  >>> title('now how much would you pay?')
  >>> xticklabels(fontsize=20, color='green')
  >>> draw()      # force a draw
  >>> savefig('alldone', dpi=300)
  >>> close()
  >>> ion()      # turn updates back on
  >>> plot(rand(20), mfc='g', mec='r', ms=40, mew=4, ls='--', lw=3)

RE: [Matplotlib-users] how to make matplotlib faster?

[Perry G. <pe...@st...>]

John Hunter Wrote:> 

> Aside from the aforementioned "run" mode of ipython, which does just
> this, the basic incantation is
> 
>   >>> from matplotlib import interactive, is_interactive
>   >>> b = is_interactive()  # store the current interactive state
>   >>> plot(blah, blah)      # make some plots
>   >>> interactive(False)    # turn interactive off
>   >>> for i in arange(1e4096): plot(arange(i), arange(i)**2)  # 
> don't try this at home
>   >>> interactive(b)        # restore previous interactive state
> 
> Basically, this is what ipython does.  This is wrapped into a single
> function "run", called like
> 
>   >>> x = 1                            # some fluff
>   >>> run ~/myexamples/simple_demo.py  # turn interactive off for run
>   >>> x = 2                            # interactive setting is restored
> 
> But of course, you can use the interactive / is_interactive functions
> in any script or interactive session.
> 
> To make this more accessible, perhaps we should add an interactive (or
> update) kwarg to plot and friends, in the same vein that we discussed
> a kwarg for hold, so you can easily do things like
> 
>   plot(x, y, hold=False)    # add plot, clearing previous
>   plot(x, y, update=False)  # add plot but do not update
> 
> But the question arises, does the additional complexity in the
> matplotlib internals required to support this justify the savings for
> the occasional user who would otherwise have to type a couple of extra
> lines?
> 
In this case I don't think so. the function interactive() is what
I was looking for, not a keyword argument. Unlike overplotting,
I think interactive() is likely to be used almost entirely in
scripts and functions and that is by far the better approach.
So it's already good enough as far as I'm concerned.

Perry 
> 
> 
> -------------------------------------------------------
> 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
> 

[Matplotlib-users] Re: Matplotlib-users digest, Vol 1 #403 - 1 msg

[Haibao T. <ba...@ug...>]

SGkgT3V5YW5nLA0KDQpGaXJzdCBjb25ncmF0dWxhdGlvbnMgb24gZmluZGluZyBtYXRwbG90
bGliLCBpdCBpcyByZWFsbHkgDQp0aGUgYmVzdC1xdWFsaXR5IHB5dGhvbiAyRCBwbG90dGlu
ZyBtb2R1bGUgeW91IGNhbiBmaW5kIG9uIA0KdGhlIHdlYiwgYW5kIHRoZSBwcm9qZWN0IGlz
IGFjdGl2ZSAoZ3JlYXQpLiBJdCBjYW4gdXNlIA0KQ2hpbmVzZSBjaGFyYWN0ZXJzLCBidXQg
bWFrZSBzdXJlIHRoYXQgeW91ciBiYWNrZW5kIERPRVNOJ1QgDQp1c2UgJ0FnZycsIGZvciBl
eGFtcGxlIHRoZSBmb2xsb3dpbmcgY29kZSB3aWxsIHdvcmsgdW5kZXIgLQ0KZFdYLCBidXQg
bm90IC1kV3hBR0c6DQoNCiMgLSotIGNvZGluZzogdXRmLTggLSotIA0KZnJvbSBtYXRwbG90
bGliLm1hdGxhYiBpbXBvcnQgKg0KZm9udCA9IHsnZm9udG5hbWUnICAgOiAnU0lNU1VOJywN
CiAgICAgICAgJ2NvbG9yJyAgICAgIDogJ3InKQ0KcGxvdChbMSwyLDNdLCdidi0nKQ0KdGl0
bGUoIuWkp+WutuWlve+8gSIuZGVjb2RlKCJtYmNzIiksZm9udCkNCnNob3coKQ0KDQpOT1RF
IHRoYXQgdGhpcyByZXF1aXJlcyB5b3VyIHN5c3RlbSB0byBiZSBXSU5ET1dTLWNoaW5lc2UN
Cihvb3BzKSwgb3RoZXJ3aXNlLCB5b3UgaGF2ZSB0byBpbnN0YWxsIHJlbGF0ZWQgY29kZWNz
IHdoaWNoIA0KaSB3aWxsIG5vdCBlbGFib3JhdGUgaGVyZS4gRm9yIHNvbWUgcmVhc29uIHRo
ZSBBZ2cgYmFja2VuZHMgDQpmYWlscyBldmVuIGlmIHlvdSBoYXZlIHRoZSByaWdodCBjb2Rp
bmcsIGluIGxpbmUgMjE5IA0KZ2V0X3RleHRfd2lkdGhfaGVpZ2h0KCksIGl0IHJhaXNlcyBh
biB1bmljb2RlIGVycm9yLiANCg0KRm9yIGEgcGllY2hhcnQsIHlvdSBjYW4gc3RhcnQgd3Jp
dGluZyB5b3VyIG93biwgSkRIIGhhcyANCmFscmVhZHkgZGVmaW5lZCBhbG1vc3QgYWxsIHRo
ZSBjb21wb25lbnRzIGZvciBkb2luZyB0aGlzLCANCmFuZCB5b3UgbWF5IGNvbnRyaWJ1dGUg
eW91ciBjb2RlIHNvbWVkYXk6KSBGb3IgYSBsYXp5IHBlcnNvbiANCmxpa2UgbWUsIEkgdGVt
cG9yYXJpbHkgdXNlIHB5dGhvbiB3cmFwcGVyIGZvciBjaGFydGRpcmVjdG9yLg0KDQpIYWli
YW8gVGFuZw0K

Re: [Matplotlib-users] how to make matplotlib faster?

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

>>>>> "Perry" == Perry Greenfield <pe...@st...> writes:

    Perry> But that made me wonder whether or not there was a need for
    Perry> some sort of switch that delayed any update for just this
    Perry> case where one is looping over many plots (say you wrote a
    Perry> ploting function that did this that you want to run in
    Perry> interactive mode, and you wanted to use basic plotting
    Perry> functions like plot). Is there a simple mechanism to turn
    Perry> off interactive mode temporarily within the function and
    Perry> restore it at the end? If not, could it be added?  (akin to
    Perry> the hold() function)

Aside from the aforementioned "run" mode of ipython, which does just
this, the basic incantation is

  >>> from matplotlib import interactive, is_interactive
  >>> b = is_interactive()  # store the current interactive state
  >>> plot(blah, blah)      # make some plots
  >>> interactive(False)    # turn interactive off
  >>> for i in arange(1e4096): plot(arange(i), arange(i)**2)  # don't try this at home
  >>> interactive(b)        # restore previous interactive state

Basically, this is what ipython does.  This is wrapped into a single
function "run", called like

  >>> x = 1                            # some fluff
  >>> run ~/myexamples/simple_demo.py  # turn interactive off for run
  >>> x = 2                            # interactive setting is restored

But of course, you can use the interactive / is_interactive functions
in any script or interactive session.

To make this more accessible, perhaps we should add an interactive (or
update) kwarg to plot and friends, in the same vein that we discussed
a kwarg for hold, so you can easily do things like

  plot(x, y, hold=False)    # add plot, clearing previous
  plot(x, y, update=False)  # add plot but do not update

But the question arises, does the additional complexity in the
matplotlib internals required to support this justify the savings for
the occasional user who would otherwise have to type a couple of extra
lines?

JDH