matplotlib-users Mailing List for matplotlib

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

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

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

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

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

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

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

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...
_______________________________________

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

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

On 2004年12月12日, 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

>> 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 2004年12月12日, 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

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...
_______________________________________

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