matplotlib-devel Mailing List for matplotlib

Helge Avlesen wrote:
> Hi,
> regarding the support for NaN's; are there plans to use that functionality
> instead of masked arrays in matplotlib routines like pcolor, contour etc.?
> solid support for Nan's ala matlab would be good imo., as I always
> seem to run into problems with array operations after some array has
> been masked.
> 
> Helge
I think we will want to have solid support for NaNs *and* masked arrays. 
 Note that NaNs are restricted to floating point; masked arrays are 
much more general, and have some other advantages. (Coming from Matlab, 
I started out as a fan of NaNs, but I have come to appreciate the masked 
array approach. The more tightly it becomes integrated in numpy, the 
better.)
I have not thought through the implementation yet. I have been thinking 
that the time to make big changes in this area will be when we can drop 
Numeric and numarray support in favor of numpy. Then we will only have 
to keep track of a single masked array implementation, and a single set 
of NaN-handling facilities.
As a possibly interim step, it would not be hard to convert arrays with 
NaNs to masked arrays at the argument processing stage of functions 
that already handle masked arrays. If numerix.isnan now works for all 
supported numeric flavors, then I could do this when I get to a suitable 
point in my axes.py reorganization. Alternatively, it can be done 
externally be the user.
There is ongoing work on the numpy side to reduce--eliminate, I 
hope--problems such as you refer to, where things go haywire when you 
use a masked array.
Eric

On 4/7/06, Darren Dale <dd...@co...> wrote:
> On Friday 07 April 2006 12:00, John Hunter wrote:
> > Is this expected to work with a more recent numarray? Is there a fix
> > that will make it work with the older versions?
>
> I wrote an isnan function for numeric-brand numerix which could also go i=
n
> _na_imports:
>
> def isnan(a):
> """y =3D isnan(x) returns True where x is Not-A-Number"""
> return reshape(array([_isnan(i) for i in ravel(a)],'b'), shape(a))
Hi,
regarding the support for NaN's; are there plans to use that functionality
instead of masked arrays in matplotlib routines like pcolor, contour etc.?
solid support for Nan's ala matlab would be good imo., as I always
seem to run into problems with array operations after some array has
been masked.
Helge

>>>>> "Andrew" == Andrew Straw <str...@as...> writes:
 Andrew> I'm pretty sure numarray.ieeespecial has defined an
 Andrew> isnan() function for quite some time (certainly by
 Andrew> numarray 1.3). I thought Darren's isnan() function
 Andrew> wouldn't be necessary except for Numeric.
Yep, this is available on 1.3.3. Using that instead. Changes in svn.
JDH

John Hunter wrote:
>>>>>>"Darren" == Darren Dale <dd...@co...> writes:
>>>>>> 
>>>>>>
>
> Darren> def isnan(a): """y = isnan(x) returns True where x is
> Darren> Not-A-Number""" return reshape(array([_isnan(i) for i in
> Darren> ravel(a)],'b'), shape(a))
>
>OK, thanks. I committed that.
> 
>
I'm pretty sure numarray.ieeespecial has defined an isnan() function for
quite some time (certainly by numarray 1.3). I thought Darren's isnan()
function wouldn't be necessary except for Numeric.

>>>>> "Darren" == Darren Dale <dd...@co...> writes:
 Darren> def isnan(a): """y = isnan(x) returns True where x is
 Darren> Not-A-Number""" return reshape(array([_isnan(i) for i in
 Darren> ravel(a)],'b'), shape(a))
OK, thanks. I committed that.
JDH

On Friday 07 April 2006 12:00, John Hunter wrote:
> I just noticed that isnan handling is breaking backend_ps with
> numarrray 1.3.3
>
> In [1]: import matplotlib; matplotlib.rcParams['numerix'] = 'numarray'
> In [2]: import numarray
> In [3]: numarray.__version__
> Out[3]: '1.3.3'
> In [4]: from matplotlib.numerix import isnan
> ------------------------------------------------------------
> Traceback (most recent call last):
> File "<ipython console>", line 1, in ?
> ImportError: cannot import name isnan
>
> Is this expected to work with a more recent numarray? Is there a fix
> that will make it work with the older versions?
I wrote an isnan function for numeric-brand numerix which could also go in 
_na_imports:
def isnan(a):
 """y = isnan(x) returns True where x is Not-A-Number"""
 return reshape(array([_isnan(i) for i in ravel(a)],'b'), shape(a))

I just noticed that isnan handling is breaking backend_ps with
numarrray 1.3.3
 In [1]: import matplotlib; matplotlib.rcParams['numerix'] = 'numarray'
 In [2]: import numarray
 In [3]: numarray.__version__
 Out[3]: '1.3.3'
 In [4]: from matplotlib.numerix import isnan
 ------------------------------------------------------------
 Traceback (most recent call last):
 File "<ipython console>", line 1, in ?
 ImportError: cannot import name isnan
Is this expected to work with a more recent numarray? Is there a fix
that will make it work with the older versions?
JDH

On Thursday 06 April 2006 17:47, Christopher Barker wrote:
> Darren Dale wrote:
> > On Wednesday 05 April 2006 18:42, Christopher Barker wrote:
> >> Why not have a TexTempDir attribute stored somewhere, and write
> >> everything there?
> >
> > That's exactly what I'm trying to do. Or maybe I dont understand what you
> > are suggesting.
>
> I'm confused about what "working directory" you're talking about. I
>
> thought you meant Python's working directory:
> >>> os.getcwd()
>
> However, if you mean a sub-process's working directory:
>
> os.system("cd temp; ls")
Thank you for that suggestion, it turned out to be an acceptable solution. 
Changes in svn 2274.
I hope the recent lack of bug reports concerning the usetex option is an 
indication that the current implementation is approaching stability. I dont 
know if I have mentioned it here, but I think I worked out the clipping 
problems we were having with ghostscript-7.07. At any rate, I would 
appreciate some testing now, since I changed the way subprocesses are handled 
and where temporary files are created.
Darren

As a follow-up to my message on the users list dated 23 March, here are 
some patches for one of you keen developers. Here's the message to save 
you looking it up:
> I've found the source of this figimage problem. In _backend_agg.cpp
> RendererAgg::draw_image is expecting 4 arguments and is being passed
> 5 by the FigureImage draw method in image.py The offending line is:
> 
> renderer.draw_image(self.ox, self.oy, im, self.origin,
> self.figure.bbox)
> 
> Changing this to
> 
> renderer.draw_image(self.ox, self.oy, im, self.figure.bbox)
> 
> solved the problem for me.
> 
> I checked and found that the RendererAgg draw_image() virtual method
> has 5 arguments, which seems to be the source of the problem, so
> either this needs changing or the backend code does.
> 
> _draw_image() in backend_agg.py makes the call with 3 arguments, so
> this needs fixing too.
> 
> The draw_image() method in backend_emf.py has a stub override with 5
> arguments, so this may need changing too, although it isn't causing
> harm yet. I'm not sure all of these are real problems because I
> didn't try too hard to understand how the backends work.
I don't really know what to exercise to test these out. I'm not familiar 
enough with all the interactions. The patches deal directly with my 
above findings, but could well break something. With those caveats, here 
are the patches (also attached). The one which absolutely needs fixing 
is image.py. The others are what I'm guessing needs to be done to clean 
up the slight messiness I found.
Gary R.
--- image.py	2006年04月07日 22:02:08.000000000 +1000
+++ new_image.py	2006年04月07日 23:02:36.000000000 +1000
@@ -422,7 +422,7 @@
 def draw(self, renderer, *args, **kwargs):
 if not self.get_visible(): return
 im = self.make_image()
- renderer.draw_image(self.ox, self.oy, im, self.origin, 
self.figure.bbox)
+ renderer.draw_image(self.ox, self.oy, im, self.figure.bbox)
 def write_png(self, fname):
 """Write the image to png file with fname"""
--- backend_emf.py	2006年04月07日 22:51:12.000000000 +1000
+++ new_backend_emf.py	2006年04月07日 23:18:02.000000000 +1000
@@ -179,15 +179,11 @@
 
self.emf.Arc(int(x-hw),int(self.height-(y-hh)),int(x+hw),int(self.height-(y+hh)),int(x+math.cos(angle1*math.pi/180.0)*hw),int(self.height-(y+math.sin(angle1*math.pi/180.0)*hh)),int(x+math.cos(angle2*math.pi/180.0)*hw),int(self.height-(y+math.sin(angle2*math.pi/180.0)*hh)))
- def draw_image(self, x, y, im, origin, bbox):
+ def draw_image(self, x, y, im, bbox):
 """
 Draw the Image instance into the current axes; x is the
 distance in pixels from the left hand side of the canvas. y is
- the distance from the origin. That is, if origin is upper, y
- is the distance from top. If origin is lower, y is the
- distance from bottom
-
- origin is 'upper' or 'lower'
+ the distance from the origin.
 bbox is a matplotlib.transforms.BBox instance for clipping, or
 None
--- backend_agg.py	2006年04月07日 22:51:38.000000000 +1000
+++ new_backend_agg.py	2006年04月07日 23:04:00.000000000 +1000
@@ -155,14 +155,14 @@
 gcEdge, rgbFace, x, y, width/2, height/2) # ellipse takes 
radius
- def _draw_image(self, x, y, im):
+ def _draw_image(self, x, y, im, bbox):
 """
 Draw the Image instance into the current axes; x, y is the
 upper left hand corner of the image
 """
 if __debug__: verbose.report('RendererAgg.draw_image', 
'debug-annoying')
 #self._renderer.draw_image(int(x), int(self.height-y), im)
- self._renderer.draw_image(int(x), int(y), im)
+ self._renderer.draw_image(int(x), int(y), im, bbox)
 def draw_line(self, gc, x1, y1, x2, y2):
 """
--- backend_agg2.py	2006年04月07日 22:56:56.000000000 +1000
+++ new_backend_agg2.py	2006年04月07日 23:04:20.000000000 +1000
@@ -90,7 +90,7 @@
 def draw_arc(self, gcEdge, rgbFace, x, y, width, height, angle1, 
angle2):
 pass
- def draw_image(self, x, y, im, origin, bbox):
+ def draw_image(self, x, y, im, bbox):
 pass
 def draw_line(self, gc, x1, y1, x2, y2):