matplotlib-users Mailing List for matplotlib (Page 2)

On Mar 29, 2007, at 2:49 PM, Iyer wrote:
>
> Thanks for your response, what I'm trying to find - is a way to 
> have the whole subplot stop displaying non-data related parts of 
> it, like when we use the back and forward arrows on the matplotlib 
> toolbar, the subplot goes off the boundaries and can display as 
> white space (or the color of the subplot background).
>
> Please find attached an image - hope this will better illustrate 
> what I was trying to convey. If the subplot in the image stops 
> "scrolling" or rolling when it's boundaries are reached, it would 
> be nice.
Ah, I think understand what you're looking for now. You want the 
pylab toolbar to stop panning when you reach the end of the data 
range instead of continuing over into an empty area. Does that sound 
right to you?
> I was trying to find if the whole subplot could be enclosed within 
> a scrollbar, JDH says that is not possible.
I believe you may have been asking the wrong question. ;-)
Based on my understanding of things it should be possible to add this 
feature to the toolbar, assuming one can easily determine the 
bounding box of the plot in axes coordinates. One of the devs might 
be able to implement it for you, although I obviously cannot speak 
for them.
Ken

Peter Melchior wrote:
> Hello,
> 
> I understand that hold() creates a axes if there is none.
> What I want to do is plotting a couple of plots in each of the subplots.
> 
> The data I want to display is stored in a set of files, thus I have a
> loop of plot calls in each subplot:
> 
> hold(True)
> subplot(311)
> for i in range(8):
> bins = somefunction(i)
> data = someotherfunction(i)
> plot(bins,data)
> subplot(312)
> for i in range(8):
> ...
> 
> That's why I want to ensure that hold is set to True.
> Is there a better way of achieving that?
One way is this:
ax = subplot(311)
ax.hold(True)
Or this:
subplot(311)
hold(True)
The plot command will not change the hold state unless you tell it to by 
giving it a hold kwarg, in which case it will only temporarily change 
it--the change will not affect the next plot command.
Another way is to set the default via the rcParams array, as in many of 
the example scripts that come with the source distribution, or via the 
matplotlibrc file. In both cases, it is the axes.hold parameter. The 
default is True, so unless you have a non-default matplotlibrc file, you 
should be getting the behavior you want without having to do anything at 
all. Still, setting it explicitly in your script is a good idea because 
it makes it clear what is going on, and it makes the script immune to 
changes in the matplotlibrc file.
Eric
> 
> Best regards,
> 
> Peter Melchior
> 
> 
> 
> Eric Firing wrote:
>> The pylab hold command sets the hold variable for the current axes. 
>> If there is none, it makes one, hence the full-size axes on which your
>> subplots are superimposed. The hold variable determines whether
>> subsequent calls to something like "plot" erase the axes first, or
>> superimpose their drawing on whatever was already there.
>>
>> What is it you are really trying to do?
>>
>> Eric
>>
>> Peter Melchior wrote:
>>> Hello everybody,
>>>
>>> when using this very simple script, I get three subplots which lie on
>>> top of a
>>> empty plot covering the whole area of the figure:
>>>
>>> from numpy import *
>>> from pylab import *
>>>
>>> hold(True)
>>> subplot(311)
>>> subplot(312)
>>> subplot(313)
>>> show()
>>>
>>> The result of this code can be viewed here:
>>> https://www.ita.uni-heidelberg.de/~pmelchior/subplot_overlay.png
>>>
>>> If I leave out the line "hold(True)", which could also read
>>> "hold(False)", the
>>> underlying plot disappears.
>>>
>>> Is there a way to avoid that? Or: Is there a preferred position for
>>> the "hold"
>>> command?
>>>
>>> Best regards,
>>>
>>> Peter Melchior 

forgot "reply to all"

Eric,
Python 2.5 (precompiled binary)
SciPy 0.5.2 (precompiled binary)
matplotlib 0.8737 (win32-py2.5 precompiled binary)
and if it matters I'm running in iPython for all this work.
The script is:
----
from scipy import *
from pylab import *
import matplotlib.numerix.ma as ma
N = 10
y = linspace(0, pi, N)
x = linspace(0, pi, N)
z = randn( N, N)
zm = ma.masked_where( z > 0.3, z)
pcolor( x, y, zm)
----
and the result I get is:
----
In [11]: execfile('pcolor_issue.py')
---------------------------------------------------------------------------
<type 'exceptions.ValueError'> Traceback (most recent call last)
C:\Documents and Settings\phays\My Documents\NDS\PDOP\<ipython console> in
<module>()
C:\Documents and Settings\phays\My Documents\NDS\PDOP\pcolor_issue.py in
<module>()
 7 x = linspace(0, pi, N)
 8 z = randn( N, N)
 9 zm = ma.masked_where( z > 0.3, z)
 10
---> 11 pcolor( x, y, z)
C:\apps\py\lib\site-packages\matplotlib\pylab.py in pcolor(*args, **kwargs)
 1941 hold(h)
 1942 try:
-> 1943 ret = gca().pcolor(*args, **kwargs)
 1944 draw_if_interactive()
 1945 except:
C:\apps\py\lib\site-packages\matplotlib\axes.py in pcolor(self, *args,
**kwargs)
 3788 raise TypeError, 'Illegal arguments to pcolor; see
help(pcolor)'
 3789
-> 3790 Nx, Ny = X.shape
 3791
 3792 # convert to MA, if necessary.
<type ' exceptions.ValueError'>: need more than 1 value to unpack
----
On 3/29/07, Eric Firing <ef...@ha...> wrote:
>
> Pcolor accepts non-integer values of X and Y, so I don't know what the
> problem is. Please post a minimal but complete script that illustrates
> the error, and say what version of mpl you are using. With moderately
> recent versions, using masked arrays should work fine.
>
> Eric
>
> Park Hays wrote:
> > I have bogus values I don't want to display in a gridded data set
> > (regions of non-convergence, for example). pcolor does exactly what I
> > want with a masked array, except the X and Y arguments must be integer
> > arrays (as far as I can tell) and my data X and Y points are not integer
> > arrays. An approximation of what is happening goes like:
> >
> > x = linspace( 0, pi, 100)
> > y = linspace( -pi/2, pi/2, 30)
> > ev = custom_func( x, y)
> > print sum( isnan( ev))
> > 12 (or whatever)
> >
> > ev_m = ma.mask_where( isnan( ev), ev)
> > pcolor( x, y, ev_m) <-- this will fail, with an error like "need more
> > than one value to unpack" which I think is caused by the non-integer
> > nature of x, y.
> >
> >
> > Any suggestions for how can I can address this? My preference is to use
> > pcolor, because of the transparency. I am not a fan of the scipy
> > discussion regarding user-driven normalization "sentinels" to catch the
> > bogus values. Masked arrays seem so much more flexible.
> >
> > -Park
>
>

The pylab hold command sets the hold variable for the current axes. If 
there is none, it makes one, hence the full-size axes on which your 
subplots are superimposed. The hold variable determines whether 
subsequent calls to something like "plot" erase the axes first, or 
superimpose their drawing on whatever was already there.
What is it you are really trying to do?
Eric
Peter Melchior wrote:
> Hello everybody,
> 
> when using this very simple script, I get three subplots which lie on top of a
> empty plot covering the whole area of the figure:
> 
> from numpy import *
> from pylab import *
> 
> hold(True)
> subplot(311)
> subplot(312)
> subplot(313)
> show()
> 
> The result of this code can be viewed here:
> https://www.ita.uni-heidelberg.de/~pmelchior/subplot_overlay.png
> 
> If I leave out the line "hold(True)", which could also read "hold(False)", the
> underlying plot disappears.
> 
> Is there a way to avoid that? Or: Is there a preferred position for the "hold"
> command?
> 
> Best regards,
> 
> Peter Melchior
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Pcolor accepts non-integer values of X and Y, so I don't know what the 
problem is. Please post a minimal but complete script that illustrates 
the error, and say what version of mpl you are using. With moderately 
recent versions, using masked arrays should work fine.
Eric
Park Hays wrote:
> I have bogus values I don't want to display in a gridded data set 
> (regions of non-convergence, for example). pcolor does exactly what I 
> want with a masked array, except the X and Y arguments must be integer 
> arrays (as far as I can tell) and my data X and Y points are not integer 
> arrays. An approximation of what is happening goes like:
> 
> x = linspace( 0, pi, 100)
> y = linspace( -pi/2, pi/2, 30)
> ev = custom_func( x, y)
> print sum( isnan( ev))
> 12 (or whatever)
> 
> ev_m = ma.mask_where( isnan( ev), ev)
> pcolor( x, y, ev_m) <-- this will fail, with an error like "need more 
> than one value to unpack" which I think is caused by the non-integer 
> nature of x, y.
> 
> 
> Any suggestions for how can I can address this? My preference is to use 
> pcolor, because of the transparency. I am not a fan of the scipy 
> discussion regarding user-driven normalization "sentinels" to catch the 
> bogus values. Masked arrays seem so much more flexible.
> 
> -Park
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

On Mar 29, 2007, at 10:55 AM, Iyer wrote:
>
> That's unfortunate that a subplot cannot be bounded within a 
> scrollbar.. I guess if it could be possible to turn a subplot into 
> a GUI widget and have GUI widgets over another GUI widget (the 
> frame), that'd be good...
I think that wouldn't be good at all, for a simple reason: matplotlib 
has no way of calculating how big a figure or subplot should be. 
Instead, it's up to the programmer to determine what the appropriate 
size is. It can also be tedious and error-prone to do fixed layouts 
with stacked widgets, depending on the GUI toolkit you're using.
Because plotting is so flexible and matplotlib supports so many kinds 
of plots, I believe it would hard to come up with general algorithm 
to determine how big to make a figure or subplot. It gets even more 
complicated if you start considering things like resolution 
independent plotting -- different operating systems and displays can 
have dots-per-inch ratios and PNG or PS files will almost certainly 
have different DPIs than the graphical displays.
> I was wondering how we can differentiate between data on a subplot 
> and the background. i.e, if there is a subplot such as:
>
> _________________________________
> | ______/\___ |
> | / \ |
> | \ |
> |_________________________________|
>
> what could be the best way to predict where the subplot starts and 
> ends ?
I'm afraid I can't read your diagram at all... Mac Mail might have 
mangled it.
Personally, I think you ought to reconsider how you're designing your 
application. Scrolling subplots sounds like a really confusing 
interface to me. I think you might be a lot happier zooming in on 
interesting things with a mouse or splitting your plots up into 
multiple separate figures.
Ken

I am sampling over the surface of a sphere. I evaluate a function at each
position (like lat and lon or phi and theta)--the function I evaluate is
fairly expensive. As a result I don't want to sample like:
theta = linspace( -pi, pi, Ntheta)
phi = linspace( 0, pi/2, Nphi)
since theta will be grossly oversampled near the poles. There are a lot of
solutions to this, but all require modifying the sampling near the poles. I
use something I call "geodesic sampling", but there are other approaches.
See http://newsreader.mathworks.com/WebX/.ef0dfad?50...@44...Vebg6y5bv@ for
some talk on the concept.
The crappy thing about working in these irregular sample spaces is that
visualization is very difficult. I would be delighted to use Basemap in
conjunction with these, but my understanding is that Basemap requires a
regular grid. Scatter plots (with the value attribute assigned to color or
marker size) are still mediocre because the user loses the sense of
connectivity between the points.
Any thoughts on:
resampling an irregular grid?
displaying and graphing?
-Park

I have bogus values I don't want to display in a gridded data set (regions
of non-convergence, for example). pcolor does exactly what I want with a
masked array, except the X and Y arguments must be integer arrays (as far as
I can tell) and my data X and Y points are not integer arrays. An
approximation of what is happening goes like:
x = linspace( 0, pi, 100)
y = linspace( -pi/2, pi/2, 30)
ev = custom_func( x, y)
print sum( isnan( ev))
 12 (or whatever)
ev_m = ma.mask_where( isnan( ev), ev)
pcolor( x, y, ev_m) <-- this will fail, with an error like "need more than
one value to unpack" which I think is caused by the non-integer nature of x,
y.
Any suggestions for how can I can address this? My preference is to use
pcolor, because of the transparency. I am not a fan of the scipy
discussion regarding user-driven normalization "sentinels" to catch the
bogus values. Masked arrays seem so much more flexible.
-Park

Hello everybody,
when using this very simple script, I get three subplots which lie on top of a
empty plot covering the whole area of the figure:
from numpy import *
from pylab import *
hold(True)
subplot(311)
subplot(312)
subplot(313)
show()
The result of this code can be viewed here:
https://www.ita.uni-heidelberg.de/~pmelchior/subplot_overlay.png
If I leave out the line "hold(True)", which could also read "hold(False)", the
underlying plot disappears.
Is there a way to avoid that? Or: Is there a preferred position for the "hold"
command?
Best regards,
Peter Melchior

That's unfortunate that a subplot cannot be bounded within a scrollbar.. I guess if it could be possible to turn a subplot into a GUI widget and have GUI widgets over another GUI widget (the frame), that'd be good...
 
 I was wondering how we can differentiate between data on a subplot and the background. i.e, if there is a subplot such as:
_________________________________
| ______/\___ |
| / \ | 
| \ |
|_________________________________|
what could be the best way to predict where the subplot starts and ends ?
thanx, iyer
 
John Hunter <jd...@gm...> wrote: On 3/26/07, lazardo wrote:
>
> Thanks for your helpful response.
>
> I used wx, I'm mystified to as how to make the scroll bars bound the
> subplot. not the frame. The gtk example you pointed me to creates horizontal
> and vertical scrollbars around the whole frame, not within the subplot.
> i.e., if the subplot is very large , scrollbars bounding the subplot would
> be great..
This is not possible. The subplot is not a GUI widget in matplotlib,
it is part of the entire FigureCanvas, which is a widget. You can
make the Axes take up all of the figure area if you want
ax = axes([0,1,0,1])
but then you will not see you tick labels and axis labels as they will
be outside the canvas area....
JDH
 
---------------------------------
Bored stiff? Loosen up...
Download and play hundreds of games for free on Yahoo! Games.

Hi all,
I'd like to suggest an improvement to the plot window when used from
GTK. I'm using Matplotlib 0.87.5, so perhaps this has already been
fixed, not sure.
The issue is a small thing with usability when saving files of different
types. I most often save my plots as EPS or PNG files but sometimes
SVG. The issue is that the default file type is "PNG", and the save
window doesn't make any correct to that default, even if I type
"myplot.eps".
I think that the best behaviour would be
 * if I type a (valid) file extension, use that as the file type
 * if I don't type any file extension, use the selected one (and
 default to PNG)
 * if I type and extension and then change the filetype dropdown, the
 extension I typed should be changed to match the selected filetype.
If someone could point me at the relevant bit of code I could have a go
at doing it myself, else I'd be happy to test it or whatever.
Cheers
JP
-- 
John Pye
Department of Mechanical and Manufacturing Engineering
University of New South Wales, Sydney, Australia
http://pye.dyndns.org/

I've installed in my machine in the following order
python 2.5
numpy 1.01
matplot lib 0.87
scipy 0.52
wxPython 2.8
with no problem
I've also installed the same packages at home and in another two 
computer and everything went fine.
The I was asked to install this "configuaration" in some classroom 
machines and also on another computer and I continue getting this error
The import of the numpy version of the _transforms module,
_ns_transforms, failed. This is is either because numpy was
unavailable when matplotlib was compiled, because a dependency of
_ns_transforms could not be satisfied, or because the build flag for
this module was turned off in setup.py. If it appears that
_ns_transforms was not built, make sure you have a working copy of
numpy and then re-install matplotlib. Otherwise, the following
traceback gives more details:
Traceback (most recent call last):
 File "<pyshell#2>", line 1, in <module>
 from pylab import *
 File "C:\Python25\Lib\site-packages\pylab.py", line 1, in <module>
 from matplotlib.pylab import *
 File "C:\Python25\Lib\site-packages\matplotlib\pylab.py", line 201, in 
<module>
 from axes import Axes, PolarAxes
 File "C:\Python25\Lib\site-packages\matplotlib\axes.py", line 14, in 
<module>
 from artist import Artist, setp
 File "C:\Python25\Lib\site-packages\matplotlib\artist.py", line 4, in 
<module>
 from transforms import identity_transform
 File "C:\Python25\Lib\site-packages\matplotlib\transforms.py", line 
223, in <module>
 from _transforms import Value, Point, Interval, Bbox, Affine
 File "C:\Python25\Lib\site-packages\matplotlib\_transforms.py", line 
17, in <module>
 from matplotlib._ns_transforms import *
ImportError: DLL load failed: Impossibile trovare il modulo specificato
but I can assure that If I check numpy installation before installing 
matplot lib it seems everything fine.
All computer have Windows XP home edition 2002 SP2
the only difference is in the RAM quantity. (more than 256 in the 
computer where everything works) but it seems so strange to me that it 
is the ram (I've also installed in another computer , old one, and 
everything works)
Any IDEA ????
Thanks in advance for any suggestion
Giorgio

Hi,
After a few trials and errors I could finally set up plots the way I wanted by 
modifying the matplotlibrc resource. In an essence, I want bright information 
(fonts,lines) on dark background (figure bg, axes bg) and I can fully achieve 
this goal while DISPLAYING plots. However, SAVING damages their colors 
ingloriously (I could not trace down the rule what is aimed to be achieved) 
and tweaking the two options in the example matplotlibrc (savefig.facecolor 
and savefig.edgecolor) would not help. In matlab there is a switch to disable 
color inversion for hard copies: anything equivalent in the (otherwise 
excelent) matlibplot?
Thanks a lot,
Dominik
-- 
Dominik Szczerba, PhD
Computer Vision Lab CH-8092 Zurich
http://www.vision.ee.ethz.ch/~domi

On 3/28/07, Niklas Saers <nik...@gm...> wrote:
> Hi guys,
> I'm trying to make a specgram() for some wave samples that I have read into
> 'data' using pyaudiolab's read_frames() (put into wavread())
>
> When I do
>
> from wavread import *
> from pylab import *
> from statistics import *
>
> data, datasize, samplerate, channels = wavread("myfile.wav")
> specgram(data)
>
> I get:
> Warning: divide by zero encountered in log10
> (array([[ 2.26730611e-02, 1.51890672e-02, 7.78123371e-03, ...,
> 0.00000000e+00, 0.00000000e+00, 0.00000000e+00],
> [ 9.11969843e-03, 2.81931459e-03, 3.13995580e-03, ...,
So there is no traceback, just a warning?
Perhaps you could pickle or otherwise store "data" and write a simple
test script which doesn't depend on any external packages (eg
waveread) and post a link to the files and we'll take a look. My
guess is that there is some frequency that has no power and the call
to Z = 10*log10(Pxx) is failing because Pxx is zero for that
frequency. We've seen this before, and if anyone has a suggestion on
how this case *should* be handled, I'd be happy to hear some
suggestions.
JDH
JDH

On Mar 28, 2007, at 6:03 PM, Antonino Ingargiola wrote:
> On 3/28/07, Ken McIvor <mc...@ii...> wrote:
>> You should probably do the acquisition asynchronously by running it
>> in a separate thread.
<snip>
>
> That's exactly what I'd like to do. The problem is that if I run
> gtk.main() (the gtk main GUI loop) in a separate thread the program
> stops until I do something on the GUI (for example passing the mouse
> on it).
Does it do this if you run gtk.main() in the main thread (e.g. the 
interpreter prompt) while doing something else in a background thread?
> My understanding so far is the following. When the function
> that execute gtk.main() is executed, python doesn't switch thread
> until either 100 bytecode instructions are executed or since an I/O
> (potentially) blocking operation in executed.
I think you're more or less correct but are unaware of one important 
factor. Here's my understanding of how multithreading works in 
Python...
Thread switching is controlled by something called the Global 
Interpreter Lock, which is implemented in an abstract way on top of 
an OS lock/mutex object. Only one Python thread runs at a time 
because the Python interpreter requires a thread to hold the GIL 
before it can execute bytecode instructions. The running thread 
holds the GIL while is executes 100 instructions. During this time 
other Python threads block waiting to acquire the GIL. After it has 
executed its 100 instructions, the running thread releases the GIL 
and then attempts to reacquire it. The OS ensures that things are 
fair by preventing one thread from reacquiring the GIL over and over 
again when other threads are also waiting for it.
Python doesn't actually detect you do something that will block the 
thread, like an I/O operation. Instead, the C code implementing an I/ 
O operation like file.write() releases the GIL before performing the 
operation. This allows a different thread to acquire it and run some 
more bytecode instructions while the first thread performs its I/O 
operation.
> When I'm doing nothing on the GUI application, neither 100 byte 
> code instructions are executed in the thread neither an I/O call is 
> performed, so the whole program (including the *other* threads) 
> stalls.
I'm not sure on the details, but the C code that implements gtk.main 
() almost certainly releases the GIL before running the GUI event 
loop. Otherwise things like iPython wouldn't be able to run the GUI 
in a separate thread. So, that's probably not the problem.
It's possible that there's another lock that's used to protect access 
to the gtk module. If that's the case you could be causing deadlock 
by calling making gtk calls from multiple threads. In my experience 
it's best to stick to the one-thread rule: the thread that runs the 
GUI's event loop is the only thread that's allowed to do anything 
related to the GUI.
> Basically, I don't know which is the right way to put a Gtk GUI in
> background, while another thread get the data asynchronously.
You probably want to put the GUI in the main thread. The main thread 
is the only thread in a Python program that receives the 
KeyboardInterrupt exception when the process receives a SIGINT (i.e. 
when the user hits ^C in the shell). Also, most Python GUI toolkits 
require their event loops run from the thread that originally 
imported the module.
> BTW, the timer idea is good and eliminates the need to call
> asynchronously the GUI thread to update the plot, which seems (the
> latter case) not very simple to do.
Yep. It's impossible to inject arbitrary code into a Python thread; 
the thread has to figure out what it's supposed to do by periodically 
polling something or retrieving some kind of message by blocking on a 
queue. Blocking on a queue isn't an option for the GUI thread.
You might be able to trigger Gtk signals from a separate thread but 
in my experience tricks like that can be, well, tricky.
> Thanks to your suggestion to use the image.set_data method I've
> created a simplified script (pasted at the end) that demonstrate how
> to do live-update while acquiring (jep!).
Glad I could help! :-)
> The last think I'm not yet able to do is to update the colorbar to
> autoscale with the new incoming data. The the script that follows
> tries to update the colorbar too but it does not work (on matplotlib
> 0.87 at least).
I have no idea if this will help, but you might need to call 
AxesImage.changed() after calling AxesImage.set_data().
Ken

I forgot "reply to all".

On 3/28/07, Ken McIvor <mc...@ii...> wrote:
> On Mar 27, 2007, at 12:35 PM, Antonino Ingargiola wrote:
[cut]
> You should probably do the acquisition asynchronously by running it
> in a separate thread. That thread would read in the data one point
> at a time, perform any pre-processing, and post the results to a
> place that's shared between it and the main plotting thread. The
> main thread would periodically check and see if the shared data has
> changed and redraw the plot if needed. I'm not sure how hard this is
> to do in a reasonable way in pylab, but I've used this approach
> before in wxPython GUIs.
That's exactly what I'd like to do. The problem is that if I run
gtk.main() (the gtk main GUI loop) in a separate thread the program
stops until I do something on the GUI (for example passing the mouse
on it). My understanding so far is the following. When the function
that execute gtk.main() is executed, python doesn't switch thread
until either 100 bytecode instructions are executed or since an I/O
(potentially) blocking operation in executed. When I'm doing nothing
on the GUI application, neither 100 byte code instructions are
executed in the thread neither an I/O call is performed, so the whole
program (including the *other* threads) stalls.
Basically, I don't know which is the right way to put a Gtk GUI in
background, while another thread get the data asynchronously.
BTW, the timer idea is good and eliminates the need to call
asynchronously the GUI thread to update the plot, which seems (the
latter case) not very simple to do.
> > Furthermore, this function plot the new data above the
> > old one, so the plot becomes slower and slower while the acquisition
> > goes on. If I uncommented the cla() line, I get a plot that is blank
> > most of the time and that shows the data only for a fraction of second
> > while the new plot is performed.
> `
> You might want to consider create a mock data source that generates a
> stream of values from some pre-collected data or Python's "random"
> module. That would let you work on debugging the plotting end of
> things first. It would also make it easier for you to share your
> code with the list.
Thanks to your suggestion to use the image.set_data method I've
created a simplified script (pasted at the end) that demonstrate how
to do live-update while acquiring (jep!).
The last think I'm not yet able to do is to update the colorbar to
autoscale with the new incoming data. The the script that follows
tries to update the colorbar too but it does not work (on matplotlib
0.87 at least).
Any hints?
Many thanks so far...
Ciao,
 ~ Antono
PS: Here it is the script:
from time import sleep
from random import randint
from pylab import *
N = 5
def fake_data_generator():
 sleep(randint(1,3)/10.0)
 return rand()*100
def data_aquisition_loop():
 data = zeros((N,N))
 for j in range(N):
 for i in range(N):
 print ' - Acquiring pixel (',i,',',j,') ... '
 data[j,i] = fake_data_generator()
 plot_update(data)
 return data
def setup_plot(data):
 global image, color_bar
 title('Scanning Data')
 image = imshow(data, interpolation='nearest', origin='upper',
 extent=[0,N,N,0])
 color_bar = colorbar()
def plot_update(data):
 image.set_data(data)
 color_bar.set_array(data)
 color_bar.autoscale()
 draw()
if __name__ == '__main__':
 ion()
 setup_plot(rand(N*N).reshape(N,N))
 data_aquisition_loop()

On Mar 28, 2007, at 3:41 PM, Dav...@no... wrote:
>
> Hi! I have a wxmpl.PlotPanel object with a cross-hair style cursor
> (without the full screen crosshairs). When I select a rectangle w/ 
> this
> cursor it zooms in to that rectangle - great! Now, how do I get the
> rectangle coordinates (preferably in data coords.) from the rectangle
> selection event? Thanks!
You can subscribe to region selection events using 
wxmpl.EVT_SELECTION, which is a wxPython event. See `demos/ 
picking_points.py' for a detailed example.
Due to a failure of imagination you can currently have region 
selections zoom or emit events. If you need to do both it'll take 
some jiggery-pokery. Let me know if this is the case and I'll write 
something up.
Ken

Hi! I have a wxmpl.PlotPanel object with a cross-hair style cursor
(without the full screen crosshairs). When I select a rectangle w/ this
cursor it zooms in to that rectangle - great! Now, how do I get the
rectangle coordinates (preferably in data coords.) from the rectangle
selection event? Thanks!
DG 

jens haemmerling wrote:
> ----------------------------------------------------------------------
>
> Message: 1
> Date: 2007年3月28日 12:39:05 +0200
> From: "jens haemmerling" <jha...@gm...>
> Subject: [Matplotlib-users] surface plot...
> To: mat...@li...
> Message-ID: <200...@gm...>
> Content-Type: text/plain; charset="us-ascii"
>
>
> hello 
>
> I have problems to plot surfaces like f(x,y)=x*y...
> for example "plot_surface([1,2,3], [4,5,6], [7,8,9])" doesn't work either...
>
> I imported the following:
>
> from numpy import *
> import pylab as p
> import matplotlib.axes3d as p3
>
> does anybody have an advice?
>
> 
See "simple3d.py" in the examples:
http://matplotlib.sourceforge.net/matplotlib_examples_0.90.0.zip
-- Matt

Hi guys,
I'm trying to make a specgram() for some wave samples that I have 
read into 'data' using pyaudiolab's read_frames() (put into wavread())
When I do
from wavread import *
from pylab import *
from statistics import *
data, datasize, samplerate, channels = wavread("myfile.wav")
specgram(data)
I get:
Warning: divide by zero encountered in log10
(array([[ 2.26730611e-02, 1.51890672e-02, 7.78123371e-03, ...,
 0.00000000e+00, 0.00000000e+00, 0.00000000e+00],
 [ 9.11969843e-03, 2.81931459e-03, 3.13995580e-03, ...,
 0.00000000e+00, 0.00000000e+00, 0.00000000e+00],
 [ 7.25346631e-04, 4.83291216e-05, 2.59076878e-04, ...,
 0.00000000e+00, 0.00000000e+00, 0.00000000e+00],
 ...,
 [ 5.19279887e-08, 1.53242938e-07, 1.46461798e-07, ...,
 0.00000000e+00, 0.00000000e+00, 0.00000000e+00],
 [ 1.00769359e-07, 2.00314891e-07, 3.04618029e-07, ...,
 0.00000000e+00, 0.00000000e+00, 0.00000000e+00],
 [ 2.86252093e-08, 5.42052713e-07, 1.50494595e-07, ...,
 0.00000000e+00, 0.00000000e+00, 0.00000000e+00]]), 
array([ 0. , 0.0078125, 0.015625 , 0.0234375, 0.03125 ,
 0.0390625, 0.046875 , 0.0546875, 0.0625 , 0.0703125,
 0.078125 , 0.0859375, 0.09375 , 0.1015625, 0.109375 ,
 0.1171875, 0.125 , 0.1328125, 0.140625 , 0.1484375,
 0.15625 , 0.1640625, 0.171875 , 0.1796875, 0.1875 ,
 0.1953125, 0.203125 , 0.2109375, 0.21875 , 0.2265625,
 0.234375 , 0.2421875, 0.25 , 0.2578125, 0.265625 ,
 0.2734375, 0.28125 , 0.2890625, 0.296875 , 0.3046875,
 0.3125 , 0.3203125, 0.328125 , 0.3359375, 0.34375 ,
 0.3515625, 0.359375 , 0.3671875, 0.375 , 0.3828125,
 0.390625 , 0.3984375, 0.40625 , 0.4140625, 0.421875 ,
 0.4296875, 0.4375 , 0.4453125, 0.453125 , 0.4609375,
 0.46875 , 0.4765625, 0.484375 , 0.4921875, 0.5 ,
 0.5078125, 0.515625 , 0.5234375, 0.53125 , 0.5390625,
 0.546875 , 0.5546875, 0.5625 , 0.5703125, 0.578125 ,
 0.5859375, 0.59375 , 0.6015625, 0.609375 , 0.6171875,
 0.625 , 0.6328125, 0.640625 , 0.6484375, 0.65625 ,
 0.6640625, 0.671875 , 0.6796875, 0.6875 , 0.6953125,
 0.703125 , 0.7109375, 0.71875 , 0.7265625, 0.734375 ,
 0.7421875, 0.75 , 0.7578125, 0.765625 , 0.7734375,
 0.78125 , 0.7890625, 0.796875 , 0.8046875, 0.8125 ,
 0.8203125, 0.828125 , 0.8359375, 0.84375 , 0.8515625,
 0.859375 , 0.8671875, 0.875 , 0.8828125, 0.890625 ,
 0.8984375, 0.90625 , 0.9140625, 0.921875 , 0.9296875,
 0.9375 , 0.9453125, 0.953125 , 0.9609375, 0.96875 ,
 0.9765625, 0.984375 , 0.9921875, 1. ]), array 
([ 6.40000000e+01, 1.28000000e+02, 1.92000000e+02, ...,
 9.73440000e+04, 9.74080000e+04, 9.74720000e+04]), 
<matplotlib.image.AxesImage instance at 0x3324fa8>)
For another sample, I get a nice spectrogram. What can it be about my 
sample that would give me such an error? What is the error caused by? 
A Google on the error message provided me with nothing.
Sincerely yours
	Niklas Saers

Suresh Pillai wrote:
> The new matshow() seems to like ticks every 4 units (or multiples of 4 
> for larger scales) rather than the normal, more desirable every 5 units.
> 
> Compare:
> 
> import pylab
> matrix = pylab.rand(30,30)
> pylab.matshow(matrix)
> pylab.show()
> 
> with
> 
> import pylab
> matrix = pylab.rand(30,30)
> pylab.imshow(matrix)
> pylab.show()
> 
> Looking at the code right now, but since matshow() calls imshow(), it is 
> not obvious to me. I presume it has something to do with the line
> 
> ax = fig.add_axes([0.15, 0.09, 0.775, 0.775])
No, this determines where in the figure window the axes will be located.
> 
> in matshow(). Still learning the internals of mpl ...
It is a question of the tick locator that is used.
imshow is using the default MaxNLocator, which generally does a nice job 
but will sometimes put ticks on non-integer locations. Therefore, for 
matshow, I added a kwarg to guarantee use of integer locations. I 
should be able to tweak it so that its results differ from the default 
MaxNLocator only when the latter would produce non-integers. That was 
the intention.
> 
> Also, as mentioned in a previous thread, the new matshow() is missing tick 
> marks on the lower x-axis.
I thought I fixed that in svn, but it looks like I was foiled by a bug 
somewhere in axis.py. I'll have to track it down. To be continued...
Eric
> 
> Cheers,
> Suresh

On 3/29/07, John Hunter <jd...@gm...> wrote:
> On 3/28/07, Giorgio F. Gilestro <gil...@gm...> wrote:
> > Hi,
> > I have to question that will help some colleagues/friends of mine to switch
> > to python from matlab.
> >
> > 1 - is there an automatic translator of code from matlab to
> > python/numpy/matplotlib? I believe it would be very easy to implement due
> > the similar syntax between the two. I could do something similar myself but
> > first I better make sure it doesn't exist yet.
>
> None that I know of, and it probably wouldn't be easy. For one thing,
> matlab uses parentheses for function calls and indexing, and it is
> probably not always obvious which is which for a translator. One
> could write something that got it mostly right and flagged
> ambiguities, but I think you should expect that a human would have to
> clean it up afterwards unless you attempt something ambitious and not
> easy. Prove me wrong!
Another thing that is maybe even more problematic is that matlab uses
call-by-value and value-based assignment while Python/Numpy uses
call-by-reference and reference-based assignment. So in matlab
 A = B;
 A(3,2) = 22;
will not modify B, but the equivalent numpy code
 A = B
 A[2,1] = 22
will modify both A and B. That means for a translator to create
efficient code it really needs to analyze if each copy created is ever
modified, and if so whether that matters. So I think you'd need to do
a full parsing of the matlab code. No regexp tricks are going to cut
it.
Another very tricky thing is that the indexing rules are very
different. Any time you see something like A(idx) in matlab you have
to really know what type of thing idx is exactly in order to translate
it properly. And then there's the issue with matlab code that calls
"SomeNonTrivialToolboxRoutine(x)". Even if it does exist in SciPy,
often the parameters are very different. And there's the one-based vs
zero-based thing. But that's probably the least of one's worries.
So there are a lot of challenges. But none of it seems impossible,
and there are some shortcuts you could take to get something that
would still be a useful first-pass, but require hand touch-up.
On the plus side, it's probably easier to translate from a
pass-by-value language to pass-by-reference than the other way around.
--bb

The new matshow() seems to like ticks every 4 units (or multiples of 4 
for larger scales) rather than the normal, more desirable every 5 units.
Compare:
import pylab
matrix = pylab.rand(30,30)
pylab.matshow(matrix)
pylab.show()
with
import pylab
matrix = pylab.rand(30,30)
pylab.imshow(matrix)
pylab.show()
Looking at the code right now, but since matshow() calls imshow(), it is 
not obvious to me. I presume it has something to do with the line
ax = fig.add_axes([0.15, 0.09, 0.775, 0.775])
in matshow(). Still learning the internals of mpl ...
Also, as mentioned in a previous thread, the new matshow() is missing tick 
marks on the lower x-axis.
Cheers,
Suresh