matplotlib-users Mailing List for matplotlib (Page 8)

Eric Firing wrote:
> Ryan May wrote:
>> On Fri, Feb 13, 2009 at 12:08 PM, <jas...@cr... 
>> <mailto:jas...@cr...>> wrote:
>>
>>
>> A student of mine recently noticed that sometimes, quiver plots were
>> coming up empty (using the plot_vector_field function from Sage, 
>> which
>> passes everything on to quiver). Upon investigation, we saw that 
>> some
>> of the array entries passed in were infinity because of where we
>> happened to evaluate the function. It was relatively easy to 
>> correct in
>> our case (change the evaluation to miss the bad point), but is 
>> there a
>> better way to handle this? Can this be considered a bug in quiver 
>> (i.e.,
>> returning a blank plot when one of the vectors has an infinite
>> coordinate?).
>>
>> Here is some example code illustrating the problem:
>>
>>
>> import pylab
>> import numpy
>> step=1
>> X,Y = numpy.meshgrid(
>> numpy.arange(-1,1.1,step),numpy.arange(-1,1.1,step) )
>> U = 1/X
>> V = Y
>> pylab.figure()
>> Q = pylab.quiver( X,Y,U, V)
>> pylab.savefig("test.png")
>>
>> When you change step to something that avoids an evaluation at 
>> x=0 (say,
>> step=0.13), you get a nice plot.
>>
>> Is this something that we should be preprocessing in Sage before 
>> calling
>> quiver, masking those "bad" points or something? I haven't used 
>> masking
>> before, but I'd like to fix Sage's plot_vector_field function to 
>> return
>> something sensible, even when the function happens to be infinite 
>> at one
>> of the points.
>>
>>
>> I'm not sure why quiver does not plot any arrows in that case, but 
>> it's also easy enough to mask out the values yourself:
>>
>> U = 1/X
>> U = numpy.ma.array(U, mask=numpy.isinf(U))
>> V = Y
>> V = numpy.ma.array(V, mask=numpy.isinf(V))
>>
>> You can also catch NaN values by using ~numpy.isfinite() instead of 
>> numpy.isinf().
>
> This is a good use case for numpy.ma.masked_invalid:
>
> In [2]:numpy.ma.masked_invalid?
> Type: function
> Base Class: <type 'function'>
> String Form: <function masked_invalid at 0xb62bccdc>
> Namespace: Interactive
> File: /usr/local/lib/python2.5/site-packages/numpy/ma/core.py
> Definition: numpy.ma.masked_invalid(a, copy=True)
> Docstring:
> Mask the array for invalid values (NaNs or infs).
> Any preexisting mask is conserved.
>
Thanks for both of your replies. So I tried the following:
import pylab
import numpy
step=1
X,Y = numpy.meshgrid( numpy.arange(-1,1.1,step),numpy.arange(-1,1.1,step) )
U = numpy.ma.masked_invalid(1/X)
V = numpy.ma.masked_invalid(Y)
pylab.figure()
Q = pylab.quiver( X,Y,U, V)
pylab.savefig("test.png")
and I still didn't get a plot. I noticed two things:
1. The unmasked portion of each array might be different; I hope quiver 
can handle that.
2. Even when I called pylab.quiver(X,Y,U,U) (so that the masks lined 
up), I still didn't get a plot.
Does quiver handle masks properly, or did I just do something wrong?
Jason

Ryan May wrote:
> On Fri, Feb 13, 2009 at 12:08 PM, <jas...@cr... 
> <mailto:jas...@cr...>> wrote:
> 
> 
> A student of mine recently noticed that sometimes, quiver plots were
> coming up empty (using the plot_vector_field function from Sage, which
> passes everything on to quiver). Upon investigation, we saw that some
> of the array entries passed in were infinity because of where we
> happened to evaluate the function. It was relatively easy to correct in
> our case (change the evaluation to miss the bad point), but is there a
> better way to handle this? Can this be considered a bug in quiver (i.e.,
> returning a blank plot when one of the vectors has an infinite
> coordinate?).
> 
> Here is some example code illustrating the problem:
> 
> 
> import pylab
> import numpy
> step=1
> X,Y = numpy.meshgrid(
> numpy.arange(-1,1.1,step),numpy.arange(-1,1.1,step) )
> U = 1/X
> V = Y
> pylab.figure()
> Q = pylab.quiver( X,Y,U, V)
> pylab.savefig("test.png")
> 
> When you change step to something that avoids an evaluation at x=0 (say,
> step=0.13), you get a nice plot.
> 
> Is this something that we should be preprocessing in Sage before calling
> quiver, masking those "bad" points or something? I haven't used masking
> before, but I'd like to fix Sage's plot_vector_field function to return
> something sensible, even when the function happens to be infinite at one
> of the points.
> 
> 
> I'm not sure why quiver does not plot any arrows in that case, but it's 
> also easy enough to mask out the values yourself:
> 
> U = 1/X
> U = numpy.ma.array(U, mask=numpy.isinf(U))
> V = Y
> V = numpy.ma.array(V, mask=numpy.isinf(V))
> 
> You can also catch NaN values by using ~numpy.isfinite() instead of 
> numpy.isinf().
This is a good use case for numpy.ma.masked_invalid:
In [2]:numpy.ma.masked_invalid?
Type:		function
Base Class:	<type 'function'>
String Form:	<function masked_invalid at 0xb62bccdc>
Namespace:	Interactive
File:		/usr/local/lib/python2.5/site-packages/numpy/ma/core.py
Definition:	numpy.ma.masked_invalid(a, copy=True)
Docstring:
 Mask the array for invalid values (NaNs or infs).
 Any preexisting mask is conserved.
Eric
> 
> Ryan
> 
> -- 
> Ryan May
> Graduate Research Assistant
> School of Meteorology
> University of Oklahoma
> 
> 
> ------------------------------------------------------------------------
> 
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a 600ドル discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

On Fri, Feb 13, 2009 at 12:08 PM, <jas...@cr...> wrote:
>
> A student of mine recently noticed that sometimes, quiver plots were
> coming up empty (using the plot_vector_field function from Sage, which
> passes everything on to quiver). Upon investigation, we saw that some
> of the array entries passed in were infinity because of where we
> happened to evaluate the function. It was relatively easy to correct in
> our case (change the evaluation to miss the bad point), but is there a
> better way to handle this? Can this be considered a bug in quiver (i.e.,
> returning a blank plot when one of the vectors has an infinite
> coordinate?).
>
> Here is some example code illustrating the problem:
>
>
> import pylab
> import numpy
> step=1
> X,Y = numpy.meshgrid( numpy.arange(-1,1.1,step),numpy.arange(-1,1.1,step) )
> U = 1/X
> V = Y
> pylab.figure()
> Q = pylab.quiver( X,Y,U, V)
> pylab.savefig("test.png")
>
> When you change step to something that avoids an evaluation at x=0 (say,
> step=0.13), you get a nice plot.
>
> Is this something that we should be preprocessing in Sage before calling
> quiver, masking those "bad" points or something? I haven't used masking
> before, but I'd like to fix Sage's plot_vector_field function to return
> something sensible, even when the function happens to be infinite at one
> of the points.
>
I'm not sure why quiver does not plot any arrows in that case, but it's also
easy enough to mask out the values yourself:
U = 1/X
U = numpy.ma.array(U, mask=numpy.isinf(U))
V = Y
V = numpy.ma.array(V, mask=numpy.isinf(V))
You can also catch NaN values by using ~numpy.isfinite() instead of
numpy.isinf().
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

You can pass "extent=(left, right, bottom, top)" to imshow to specify 
what the pixels in the array correspond to in data space.
Mike
Lewis, Ambrose J. wrote:
>
> Hi All:
>
> I’m working on a wxPython GUI that uses matplotlib.
>
> This program reads "chunks" of a data file into a numpy array and than 
> plots it using imshow.
>
> The first chunk works great. But, when I load chunks 2 to N, how can I 
> specify the different values for the labels on the x axis?
>
> I tried using "axes.set_xlim". This did reposition the x axis as 
> hoped, but the data is always being drawn back at the "zero" offset.
>
> Is there a way to tell the axis to map the array to a different x range?
>
> I can’t read the whole file at once, it’s just too big
>
> THANXS
>
> amb
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a 600ドル discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> ------------------------------------------------------------------------
>
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Fri, Feb 13, 2009 at 12:01 PM, Lewis, Ambrose J. <
AMB...@sa...> wrote:
> Hi All:
>
> I'm working on a wxPython GUI that uses matplotlib.
>
> This program reads "chunks" of a data file into a numpy array and than
> plots it using imshow.
>
> The first chunk works great. But, when I load chunks 2 to N, how can I
> specify the different values for the labels on the x axis?
>
> I tried using "axes.set_xlim". This did reposition the x axis as hoped,
> but the data is always being drawn back at the "zero" offset.
>
> Is there a way to tell the axis to map the array to a different x range?
>
> I can't read the whole file at once, it's just too big
>
Does the 'extent' keyword argument to imshow do what you want?
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma
Sent from: Norman Oklahoma United States.

A student of mine recently noticed that sometimes, quiver plots were 
coming up empty (using the plot_vector_field function from Sage, which 
passes everything on to quiver). Upon investigation, we saw that some 
of the array entries passed in were infinity because of where we 
happened to evaluate the function. It was relatively easy to correct in 
our case (change the evaluation to miss the bad point), but is there a 
better way to handle this? Can this be considered a bug in quiver (i.e., 
returning a blank plot when one of the vectors has an infinite coordinate?).
Here is some example code illustrating the problem:
import pylab
import numpy
step=1
X,Y = numpy.meshgrid( numpy.arange(-1,1.1,step),numpy.arange(-1,1.1,step) )
U = 1/X
V = Y
pylab.figure()
Q = pylab.quiver( X,Y,U, V)
pylab.savefig("test.png")
When you change step to something that avoids an evaluation at x=0 (say, 
step=0.13), you get a nice plot.
Is this something that we should be preprocessing in Sage before calling 
quiver, masking those "bad" points or something? I haven't used masking 
before, but I'd like to fix Sage's plot_vector_field function to return 
something sensible, even when the function happens to be infinite at one 
of the points.
Thanks,
Jason
--
Jason Grout

Hi All:
I'm working on a wxPython GUI that uses matplotlib. 
This program reads "chunks" of a data file into a numpy array and than
plots it using imshow. 
The first chunk works great. But, when I load chunks 2 to N, how can I
specify the different values for the labels on the x axis?
I tried using "axes.set_xlim". This did reposition the x axis as hoped,
but the data is always being drawn back at the "zero" offset.
Is there a way to tell the axis to map the array to a different x range?
I can't read the whole file at once, it's just too big
THANXS
amb
 

On Fri, Feb 13, 2009 at 3:24 AM, Richard Jennings <rpj...@gm...>wrote:
> Hi,
>
> I am not expert in matplotlib, I use it to generate plots for a management
> performance tool.
>
> I have just upgraded this application from 0.98.3 to 0.98.5 and the
> upgrade broke the application in 3 places:
>
>
>
> 1). In units.py, Registry.get_converter(): this method has been made
> recursive in 0.98.5. The problem is that if x is a string then you get a
> recursion error.
>
> The cause is the 'iterable() function called in the line "if converter is
> None and interable(x):" The interable() function is in cbook.py and it
> actually tests to see if the object 'x' has a __len__() method. Call
> iterable() on a string and it returns true.
>
> Do " for thisx in x:" and you will always get the first character in the
> string, which is.... a string!
>
> My solution was to change iterable():
>
> Def iterable(obj):
>
> """
>
> Return true if **obj** is iterable
>
> """
>
> try: obj.__iter__()
>
> except AtributeError: return False
>
> return True
>
>
>
> this seems to have solved the problem.
>
This has been fixed on the SVN trunk. FYI, the problem with your fix above
is that, in general, we want strings to be considered iterable -- just not
in this case. It should also be noted that the purpose of the fix was to
eliminate the confusing infinite recursion. The fact that plotting strings
of numbers works is a coincidence of how matplotlib is coded up and really
should not be considered a supported feature.
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma
Sent from: Norman Oklahoma United States.

On Fri, Feb 13, 2009 at 6:24 AM, John Hunter <jd...@gm...> wrote:
> On Thu, Feb 12, 2009 at 2:13 PM, Ryan May <rm...@gm...> wrote:
> > On Wed, Feb 11, 2009 at 7:30 PM, John Hunter <jd...@gm...> wrote:
> >>
> >> On Wed, Feb 11, 2009 at 2:49 PM, Ryan May <rm...@gm...> wrote:
>
> > Well, I checked in an example that shows the functionality. The problem
> is
> > that using these events doesn't follow the standard event API. You don't
> > connect using figure.canvas.mpl_connect() (it doesn't like the names
> > 'xlim_changed' and 'ylim_changed'), but rather you use
> > Axes.callbacks.connect(). Also, the an event object is not passed into
> the
> > callback, but rather the originating axes instance. Are these events
> relics
> > to the older version of event handling that haven't been moved to the
> > present?
> >
> > Otherwise, should I add a special section to the event handling docs to
> > handle these?
>
>
> Thanks for the example -- you are right that this is a 'legacy' event
> callback outside the regular event framework. So it doesn't really
> belong in the event handling chapter but may merit a quick note there.
> Alternatively, we could rather easily draft up a special event
> (NavigationEvent?) that *does* work in the regular event handling
> framework. The quirk is that the events are handled at the canvas
> level, so it would be difficult to register for a single axes, but one
> could get a NavigationEvent if the limits of any of the axes in the
> figure were updated, and use the inaxes attribute to process it. If
> this, or some variant of it, seems like a good idea I'm happy to add
> it.
>
I'm +1 on your idea. While it may be a little quirky that you can't
register for a single axes limit change, it's even weirder that you have
different ways to register for different types of events. I think the
overall API for matplotlib is improved by bringing *all* event callbacks
under a single, unified, API. Along those lines, I see these other 'events'
being processed in the code, but not formally recognized by the canvas level
event handler:
Aixs : 'units', 'units finalize'
Figure : 'dpi_changed'
Would it be good to try to move these to the canvas-level handler as well? I
don't have a good idea myself of how that would work right now.
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

I'm just commenting on the points I know about below -- leaving the rest 
to others.
Richard Jennings wrote:
>
> 2). Backend_svg.py._get_style(): in 0.98.3, stroke_width is a string 
> and in 0.98.5 it is a float. I set the styles by reading attributes in 
> an xml file and so the strings worked. When I upgraded, I got ‘float’ 
> type errors. My opinion is that we might expect parametric 
> polymorphism here. A stroke width could be ‘1’, 1 or 1.0 all of which 
> are legitimate parameters. Hence, when we set the kwarg ‘lw’ on 
> ‘plot’, a string, int or float should be legal. Just my opinion.
>
This change was made to work around a localization bug in Numpy. In a 
French locale (for example), printing a Numpy float scalar as a string 
would be "1,2" (which is against the SVG spec) and as a float would be 
"1.2".
But you're right -- this inadvertently broke supporting strings for 
certain parameters. I'm actually of the opinion that supporting strings 
in the first place was an unintentional feature -- none of our example 
or regression code uses it. I'm not sold that this is something that 
needs to be fixed.
But at a higher level, this re-raises the recurring issue about argument 
checking. In general, matplotlib doesn't do much type checking/coercion 
at the front end (user end), which leads to these sorts of unintended 
consequences in the backend. I would like to see more argument checking 
happening earlier so the user would get more localised and appropriate 
feedback when they passed in an invalid parameter. The idea of using 
Enthought's Traits library for this was thrown around in the past, but 
at the time it was impractical. Unfortunately, in the meantime that's 
kept us from doing the obvious and straightforward thing which is just 
to do more type and value checking in the setter methods. I think it 
would make a good project to go through and add type checkers to all the 
setters, followed by other user-points of entry, but it's not the 
sexiest or most interesting thing to do, perhaps.
>
> 3). Font_manager.createFontDict() in 0.98.3 become createFontList() in 
> 0.98.5. I didn’t find this change in Changes, but maybe I’m blind. 
> What I am saying here is that if I upgrade to 0.98.5 from 0.98.3, I 
> would expect 0.98.5 to be less ‘broke’ than 0.98.3, not different.
>
matplotlib version numbering has not traditionally followed Python's 
numbering scheme where the third number implies only bug fixes. We have 
started that sort of approach only recently with 0.98.5 where 0.98.5.x 
will be bugfixes only. In the future (maybe beginning 1.0 and later) we 
can probably have a more traditional version numbering scheme, though 
there has been no formal written decision on that.
That change has to do with moving from exact matching (which was 
"broke") to nearest-neighbor font matching. It is arguable that this is 
a bugfix, in that certain font lookups which were broken before are now 
correct, even though that implies different behavior.
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Thu, Feb 12, 2009 at 2:13 PM, Ryan May <rm...@gm...> wrote:
> On Wed, Feb 11, 2009 at 7:30 PM, John Hunter <jd...@gm...> wrote:
>>
>> On Wed, Feb 11, 2009 at 2:49 PM, Ryan May <rm...@gm...> wrote:
> Well, I checked in an example that shows the functionality. The problem is
> that using these events doesn't follow the standard event API. You don't
> connect using figure.canvas.mpl_connect() (it doesn't like the names
> 'xlim_changed' and 'ylim_changed'), but rather you use
> Axes.callbacks.connect(). Also, the an event object is not passed into the
> callback, but rather the originating axes instance. Are these events relics
> to the older version of event handling that haven't been moved to the
> present?
>
> Otherwise, should I add a special section to the event handling docs to
> handle these?
Thanks for the example -- you are right that this is a 'legacy' event
callback outside the regular event framework. So it doesn't really
belong in the event handling chapter but may merit a quick note there.
 Alternatively, we could rather easily draft up a special event
(NavigationEvent?) that *does* work in the regular event handling
framework. The quirk is that the events are handled at the canvas
level, so it would be difficult to register for a single axes, but one
could get a NavigationEvent if the limits of any of the axes in the
figure were updated, and use the inaxes attribute to process it. If
this, or some variant of it, seems like a good idea I'm happy to add
it.
JDH

Hi,
I am not expert in matplotlib, I use it to generate plots for a management
performance tool.
I have just upgraded this application from 0.98.3 to 0.98.5 and the upgrade
broke the application in 3 places:
 
1). In units.py, Registry.get_converter(): this method has been made
recursive in 0.98.5. The problem is that if x is a string then you get a
recursion error.
The cause is the 'iterable() function called in the line "if converter is
None and interable(x):" The interable() function is in cbook.py and it
actually tests to see if the object 'x' has a __len__() method. Call
iterable() on a string and it returns true.
Do " for thisx in x:" and you will always get the first character in the
string, which is.... a string!
My solution was to change iterable():
Def iterable(obj):
"""
Return true if *obj* is iterable
"""
try: obj.__iter__()
except AtributeError: return False
return True
 
this seems to have solved the problem.
 
2). Backend_svg.py._get_style(): in 0.98.3, stroke_width is a string and in
0.98.5 it is a float. I set the styles by reading attributes in an xml file
and so the strings worked. When I upgraded, I got 'float' type errors. My
opinion is that we might expect parametric polymorphism here. A stroke width
could be '1', 1 or 1.0 all of which are legitimate parameters. Hence, when
we set the kwarg 'lw' on 'plot', a string, int or float should be legal.
Just my opinion.
 
3). Font_manager.createFontDict() in 0.98.3 become createFontList() in
0.98.5. I didn't find this change in Changes, but maybe I'm blind. What I
am saying here is that if I upgrade to 0.98.5 from 0.98.3, I would expect
0.98.5 to be less 'broke' than 0.98.3, not different.
 
I hope this is somehow helpful.
 
Best regards, Richard Jennings

Kaushik Ghose <Kau...@hm...> writes:
> In [2]: pylab.arange(0.5,1.0,.1)
> Out[2]: array([ 0.5, 0.6, 0.7, 0.8, 0.9]) <---- OK
>
> In [3]: pylab.arange(0.5,1.1,.1)
> Out[3]: array([ 0.5, 0.6, 0.7, 0.8, 0.9, 1. , 1.1]) <----- Not OK
The "bug" is really in numpy, which is where pylab imports arange from,
but even then it's not exactly a bug but a feature of floating-point
numerics (.1 is not exactly representable in binary floating-point, so
the equality comparison done by arange doesn't make much sense). Use
linspace if you know how many values you want:
In [4]: linspace(0.5,1.0,num=5,endpoint=False)
Out[4]: array([ 0.5, 0.6, 0.7, 0.8, 0.9])
In [5]: linspace(0.5,1.1,num=6,endpoint=False)
Out[5]: array([ 0.5, 0.6, 0.7, 0.8, 0.9, 1. ])
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

Hi,
I'm using matplotlib 0.98.5.2 on mac os X.
I get the following behavior with arange that I think is not right
In [1]: import pylab
In [2]: pylab.arange(0.5,1.0,.1)
Out[2]: array([ 0.5, 0.6, 0.7, 0.8, 0.9]) <---- OK
In [3]: pylab.arange(0.5,1.1,.1)
Out[3]: array([ 0.5, 0.6, 0.7, 0.8, 0.9, 1. , 1.1]) <----- Not OK
Thanks
-Kaushik

On Wed, Feb 11, 2009 at 7:30 PM, John Hunter <jd...@gm...> wrote:
> On Wed, Feb 11, 2009 at 2:49 PM, Ryan May <rm...@gm...> wrote:
>
> > You're looking for 'xlim_changed' and 'ylim_changed'.
> >
> > I know this can be found here:
> > http://matplotlib.sourceforge.net/api/axes_api.html
> >
> > Should we add this to
> > http://matplotlib.sourceforge.net/users/event_handling.html ?
>
> We should - perhaps you can prepare a small example ( I notice we
> don't have any) illustrating it and add a description with a pointer
> to the example in the event handling tutorial.
>
> JDH
>
Well, I checked in an example that shows the functionality. The problem is
that using these events doesn't follow the standard event API. You don't
connect using figure.canvas.mpl_connect() (it doesn't like the names
'xlim_changed' and 'ylim_changed'), but rather you use
Axes.callbacks.connect(). Also, the an event object is not passed into the
callback, but rather the originating axes instance. Are these events relics
to the older version of event handling that haven't been moved to the
present?
Otherwise, should I add a special section to the event handling docs to
handle these?
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma
Sent from: Norman Oklahoma United States.

On Wed, Feb 11, 2009 at 8:00 PM, Marjolaine Rouault <mro...@cs...>wrote:
> Hi,
>
> Thanks a lot for your comments. I did try earlier on to remove the bad
> points but came across some problems when re-ordering my array. I will try
> out the method sent to me and check the reference.
Yep, the compacting/reordering method is appropriate for fixed missing
values (typically a grid mask) but not approriate for randomly placed
missing values.
I didn't read these references, but a simple approach you can implement in
python (using for example numpy.linalg.eig applied to you covariance matrix
to compute your eofs, and then your pcs) consist in a interative method to
fill your missing value and let converge your EOF/PC.
0) first save your mask once: mask = data.mask.copy()
1) fill the missing values with the mean data.filled(data.mean())
2) make a reconstruction of your data (EOF[1:10] . PC[1:10]) after your PCA
analysis using a limited number of modes (met's say 10) : datarec
3) replace you original missing data with your reconstructed field: data =
numpy.where(mask, datarec, data)
4) restart from 1) a number of time you can fixe or detect with a criteria
based for example on the eigenvalues
5) the finally, you can use you EOFs et PCs, and has a bonus, you filled
your data!
>
>
> Regards, Marjolaine.
>
>
>
> >>> <kgd...@gm... <kgdunn%2Bn...@gm...>> 02/11/09 4:06 PM
> >>>
> Marjolaine,
>
> I am assuming your masked array entries are missing data. Multivariate
> analysis with missing data can be handled in several standard ways, however
> these methods don't appear in most Python libraries.
>
> Here are some references on the topic that will help you:
>
> [1] P.R.C. Nelson and J.F. MacGregor, 1996, "Missing data methods in PCA
> and PLS: Score calculations with incomplete observations", Chemometrics and
> Intelligent Laboratory Systems, v35, p 45-65.
>
> [2] F. Arteaga and A. Ferrer, 2002, "Dealing with missing data in MSPC:
> several methods, different interpretations, some examples", Journal of
> Chemometrics, v16, p408-418.
>
> Paper [1] deals with building a model with missing data, while paper [2]
> looks at applying an existing PCA model to new data that contains missing
> entries.
>
> Hope these help,
> Kevin
>
> Marjolaine Rouault wrote:
> >
> > Hi,
> >
> > I am struggling to do a PCA analysis on a masked array. Anybody has
> > suggestions on how to deal with masked array when doing PCAs?
> >
> > Best regards, Marjolaine.
> >
>
> Quoted from:
> http://www.nabble.com/matplotlib.mlab-PCA-analysis-tp21932808p21932808.html
>
>
>
> --
> This message is subject to the CSIR's copyright terms and conditions,
> e-mail legal notice, and implemented Open Document Format (ODF) standard.
> The full disclaimer details can be found at
> http://www.csir.co.za/disclaimer.html.
>
> This message has been scanned for viruses and dangerous content by
> MailScanner,
> and is believed to be clean. MailScanner thanks Transtec Computers for
> their support.
>
>
>
> ------------------------------------------------------------------------------
> Create and Deploy Rich Internet Apps outside the browser with
> Adobe(R)AIR(TM)
> software. With Adobe AIR, Ajax developers can use existing skills and code
> to
> build responsive, highly engaging applications that combine the power of
> local
> resources and data with the reach of the web. Download the Adobe AIR SDK
> and
> Ajax docs to start building applications today-
> http://p.sf.net/sfu/adobe-com
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
-- 
Stephane Raynaud

On Wed, Feb 11, 2009 at 2:49 PM, Ryan May <rm...@gm...> wrote:
> You're looking for 'xlim_changed' and 'ylim_changed'.
>
> I know this can be found here:
> http://matplotlib.sourceforge.net/api/axes_api.html
>
> Should we add this to
> http://matplotlib.sourceforge.net/users/event_handling.html ?
We should - perhaps you can prepare a small example ( I notice we
don't have any) illustrating it and add a description with a pointer
to the example in the event handling tutorial.
JDH

Gideon Simpson wrote:
> If I have a line that I want to animate, I can clearly write:
> 
> lineu, = plot(x,u)
> draw()
> 
> for p in range(0, N):
> 	lineu.set_ydata(u)
> draw()
> 
> Is there an analogue to set_ydata for things plots like contour, 
> contourf, etc.?
> 
No, as presently implemented, you simply have to remake the contour 
(that is, the ContourSet object) with the new data.
Eric

If I have a line that I want to animate, I can clearly write:
lineu, = plot(x,u)
draw()
for p in range(0, N):
	lineu.set_ydata(u)
draw()
Is there an analogue to set_ydata for things plots like contour, 
contourf, etc.?
-gideon

On Wed, Feb 11, 2009 at 2:34 PM, Thomas Robitaille <
tho...@gm...> wrote:
> Hi everyone,
>
> I wish to execute a certain function every time the view interval of
> a figure is updated, for example when it is changed interactively
> using the zoom rectangle or home button in WXAgg. Matplotlib must
> already be calling certain routines, such as the tick locator and
> formatters, but is there a way to execute arbitrary functions when
> the view interval is updated?
You're looking for 'xlim_changed' and 'ylim_changed'.
 I know this can be found here:
http://matplotlib.sourceforge.net/api/axes_api.html
Should we add this to
http://matplotlib.sourceforge.net/users/event_handling.html ?
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma
Sent from: Norman Oklahoma United States.

Hi everyone,
I wish to execute a certain function every time the view interval of 
a figure is updated, for example when it is changed interactively 
using the zoom rectangle or home button in WXAgg. Matplotlib must 
already be calling certain routines, such as the tick locator and 
formatters, but is there a way to execute arbitrary functions when 
the view interval is updated?
Thanks for any help,
Thomas

On Wed, Feb 11, 2009 at 20:13, Ryan May <rm...@gm...> wrote:
> On Wed, Feb 11, 2009 at 12:56 PM, Sandro Tosi <mo...@de...> wrote:
>>
>> Hello,
>> I got a script (attached, even if without the datafile has less
>> meaning) that parses a log file and plots 3 datasets. With 0.98.5.3 I
>> got this error
>> RuntimeError: maximum recursion depth exceeded
>>
>> I see the same behavior in .2 but not in 0.98.5. I remembered I've
>> copied this from an example in mpl doc, but that's all.
>>
>> Is that a regression or something wrong in the code?
>
> It looks like your script is trying to plot a list of a strings (which
> contains numbers). I checked in a fix for this on the trunk but I didn't
> bother on the branch since I figured it wasn't really supported behavior.
> Try converting the strings to numbers and you should be fine.
Indeed: adding int(res.group...) works fine, just nice how it worked
on 0.98.5 and not on .2 .3 :)
Thanks a lot,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

I just ran across this, which looks really nice. The author shows how to
use MPL and basemap to download satellite images from the recent fires
in Australia and overlay that with recent thermal hotspot data.
http://pyevolve.sourceforge.net/wordpress/?p=86

On Wed, Feb 11, 2009 at 12:56 PM, Sandro Tosi <mo...@de...> wrote:
> Hello,
> I got a script (attached, even if without the datafile has less
> meaning) that parses a log file and plots 3 datasets. With 0.98.5.3 I
> got this error
> RuntimeError: maximum recursion depth exceeded
>
> I see the same behavior in .2 but not in 0.98.5. I remembered I've
> copied this from an example in mpl doc, but that's all.
>
> Is that a regression or something wrong in the code?
It looks like your script is trying to plot a list of a strings (which
contains numbers). I checked in a fix for this on the trunk but I didn't
bother on the branch since I figured it wasn't really supported behavior.
Try converting the strings to numbers and you should be fine.
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

Hi,
Thanks a lot for your comments. I did try earlier on to remove the bad points but came across some problems when re-ordering my array. I will try out the method sent to me and check the reference.
Regards, Marjolaine.
>>> <kgd...@gm...> 02/11/09 4:06 PM >>>
Marjolaine,
I am assuming your masked array entries are missing data. Multivariate analysis with missing data can be handled in several standard ways, however these methods don't appear in most Python libraries.
Here are some references on the topic that will help you:
[1] P.R.C. Nelson and J.F. MacGregor, 1996, "Missing data methods in PCA and PLS: Score calculations with incomplete observations", Chemometrics and Intelligent Laboratory Systems, v35, p 45-65.
[2] F. Arteaga and A. Ferrer, 2002, "Dealing with missing data in MSPC: several methods, different interpretations, some examples", Journal of Chemometrics, v16, p408-418.
Paper [1] deals with building a model with missing data, while paper [2] looks at applying an existing PCA model to new data that contains missing entries.
Hope these help,
Kevin
Marjolaine Rouault wrote:
> 
> Hi,
> 
> I am struggling to do a PCA analysis on a masked array. Anybody has
> suggestions on how to deal with masked array when doing PCAs?
> 
> Best regards, Marjolaine.
>
Quoted from: 
http://www.nabble.com/matplotlib.mlab-PCA-analysis-tp21932808p21932808.html
-- 
This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. 
The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html.
This message has been scanned for viruses and dangerous content by MailScanner, 
and is believed to be clean. MailScanner thanks Transtec Computers for their support.