matplotlib-devel Mailing List for matplotlib (Page 3)

Darren Dale wrote:
> On Tuesday 21 March 2006 17:25, Jeff Whitaker wrote:
> 
>> Darren Dale wrote:
>> 
>>> On Tuesday 21 March 2006 15:43, Jeff Whitaker wrote:
>>> 
>>>> Jeff Whitaker wrote:
>>>> 
>>>>> I've noticed two problems with the postscript backend with today's
>>>>> svn. Running the basemap examples and saving to an eps or ps file:
>>>>>
>>>>> 1) dotted lines (the meridians and parallels on the basemap) show up
>>>>> as solid
>>>>>
>>>>> 2) line and text colors are wrong - if a contour plot is created, any
>>>>> lines or text that are then plotted after that show up with the same
>>>>> color as the end of the colormap (blue for a red-->blue colormap).
>>>>>
>>>>> I'll try to build a concise example that shows this later on today.
>>>>>
>>>>> -Jeff
>>>>> 
>>>> contourf_demo.py illustrates these problems - just run it and save the
>>>> output to a postscript file.
>>>> 
>>> This is fixed as of svn 2202.
>>> 
>> Darren:
>>
>> contourf_demo.py still produces the same postscript output for me with
>> svn 2202 (title shows up in red text and the dashed contours are munged).
>> 
>
> It looks fine on my system.
> 
You're right - my bad. I was looking at the old postscript file, the 
new one is indeed fine. Thanks Darren.
-Jeff
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
Meteorologist FAX : (303)497-6449
NOAA/OAR/PSD R/PSD1 Email : Jef...@no...
325 Broadway Office : Skaggs Research Cntr 1D-124
Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg

On Tuesday 21 March 2006 17:25, Jeff Whitaker wrote:
> Darren Dale wrote:
> > On Tuesday 21 March 2006 15:43, Jeff Whitaker wrote:
> >> Jeff Whitaker wrote:
> >>> I've noticed two problems with the postscript backend with today's
> >>> svn. Running the basemap examples and saving to an eps or ps file:
> >>>
> >>> 1) dotted lines (the meridians and parallels on the basemap) show up
> >>> as solid
> >>>
> >>> 2) line and text colors are wrong - if a contour plot is created, any
> >>> lines or text that are then plotted after that show up with the same
> >>> color as the end of the colormap (blue for a red-->blue colormap).
> >>>
> >>> I'll try to build a concise example that shows this later on today.
> >>>
> >>> -Jeff
> >>
> >> contourf_demo.py illustrates these problems - just run it and save the
> >> output to a postscript file.
> >
> > This is fixed as of svn 2202.
>
> Darren:
>
> contourf_demo.py still produces the same postscript output for me with
> svn 2202 (title shows up in red text and the dashed contours are munged).
It looks fine on my system.

Darren Dale wrote:
> On Tuesday 21 March 2006 15:43, Jeff Whitaker wrote:
> 
>> Jeff Whitaker wrote:
>> 
>>> I've noticed two problems with the postscript backend with today's
>>> svn. Running the basemap examples and saving to an eps or ps file:
>>>
>>> 1) dotted lines (the meridians and parallels on the basemap) show up
>>> as solid
>>>
>>> 2) line and text colors are wrong - if a contour plot is created, any
>>> lines or text that are then plotted after that show up with the same
>>> color as the end of the colormap (blue for a red-->blue colormap).
>>>
>>> I'll try to build a concise example that shows this later on today.
>>>
>>> -Jeff
>>> 
>> contourf_demo.py illustrates these problems - just run it and save the
>> output to a postscript file.
>> 
>
> This is fixed as of svn 2202.
>
> 
Darren:
contourf_demo.py still produces the same postscript output for me with 
svn 2202 (title shows up in red text and the dashed contours are munged).
-Jeff
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
Meteorologist FAX : (303)497-6449
NOAA/OAR/PSD R/PSD1 Email : Jef...@no...
325 Broadway Office : Skaggs Research Cntr 1D-124
Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg

On Tuesday 21 March 2006 15:43, Jeff Whitaker wrote:
> Jeff Whitaker wrote:
> > I've noticed two problems with the postscript backend with today's
> > svn. Running the basemap examples and saving to an eps or ps file:
> >
> > 1) dotted lines (the meridians and parallels on the basemap) show up
> > as solid
> >
> > 2) line and text colors are wrong - if a contour plot is created, any
> > lines or text that are then plotted after that show up with the same
> > color as the end of the colormap (blue for a red-->blue colormap).
> >
> > I'll try to build a concise example that shows this later on today.
> >
> > -Jeff
>
> contourf_demo.py illustrates these problems - just run it and save the
> output to a postscript file.
This is fixed as of svn 2202.
However, the transform is not being passed to draw_lines, and so the method 
works as if the old API were being used. Is this a bug? Shouldn't the 
transform be provided to draw_lines when using the new API? 

Jeff Whitaker wrote:
>
> I've noticed two problems with the postscript backend with today's 
> svn. Running the basemap examples and saving to an eps or ps file:
>
> 1) dotted lines (the meridians and parallels on the basemap) show up 
> as solid
>
> 2) line and text colors are wrong - if a contour plot is created, any 
> lines or text that are then plotted after that show up with the same 
> color as the end of the colormap (blue for a red-->blue colormap).
>
> I'll try to build a concise example that shows this later on today.
>
> -Jeff
>
contourf_demo.py illustrates these problems - just run it and save the 
output to a postscript file.
-Jeff
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
Meteorologist FAX : (303)497-6449
NOAA/OAR/PSD R/PSD1 Email : Jef...@no...
325 Broadway Office : Skaggs Research Cntr 1D-124
Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg

I've noticed two problems with the postscript backend with today's svn. 
Running the basemap examples and saving to an eps or ps file:
1) dotted lines (the meridians and parallels on the basemap) show up as 
solid
2) line and text colors are wrong - if a contour plot is created, any 
lines or text that are then plotted after that show up with the same 
color as the end of the colormap (blue for a red-->blue colormap).
I'll try to build a concise example that shows this later on today.
-Jeff
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
Meteorologist FAX : (303)497-6449
NOAA/OAR/PSD R/PSD1 Email : Jef...@no...
325 Broadway Office : Skaggs Research Cntr 1D-124
Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg

Darren Dale wrote:
> As of svn 2181, if you use a *Agg backend or the postscript backend with the 
> new API, the following script will yield a gap in the line, see attached. I 
> guess we need to decide if this is desireable behavior
+1
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
 		
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

Andrew Straw wrote:
> Taking John up on his offer to close some bugs, it looks like Jeff
> closed SF bug 1372239[1], by moving the #include "Python.h" statement
> ahead of the other includes.
>
> As mentioned in the bug report, the "official" Python/C API docs[2]
> state this is the correct behavior.
>
> Unfortunately, on my Debian sarge amd64 system, this "fix" of a compiler
> warning results in a compile error:
>
> gcc: src/_image.cpp
> In file included from /usr/include/png.h:363,
> from src/_image.cpp:6:
> /usr/include/pngconf.h:310:2: #error png.h already includes setjmp.h
> with some additional fixup.
> In file included from /usr/include/png.h:363,
> from src/_image.cpp:6:
> /usr/include/pngconf.h:310:2: #error png.h already includes setjmp.h
> with some additional fixup.
> error: Command "gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O3 -Wall
> -Wstrict-prototypes -fPIC
> -I/home/astraw/py2.3-linux-x86_64/lib/python2.3/site-packages/numpy-0.9.7.2243-py2.3-linux-x86_64.egg/numpy/core/include
> -I/usr/local/include -I/usr/include -I. -Isrc -Iswig -Iagg23/include -I.
> -I/usr/local/include -I/usr/include -I.
> -I/home/astraw/py2.3-linux-x86_64/lib/python2.3/site-packages/numpy-0.9.7.2243-py2.3-linux-x86_64.egg/numpy/core/include/freetype2
> -I/usr/local/include/freetype2 -I/usr/include/freetype2 -I./freetype2
> -Isrc/freetype2 -Iswig/freetype2 -Iagg23/include/freetype2 -I./freetype2
> -I/usr/local/include/freetype2 -I/usr/include/freetype2 -I./freetype2
> -I/usr/include/python2.3 -c src/_image.cpp -o
> build/temp.linux-x86_64-2.3/src/_image.o -DSCIPY=1" failed with exit
> status 1
>
> Googling on this indicates this libpng's setjmp() redefinition may be
> responsible[3]. This looks like a real issue with Python.h and png.h and
> not something we have much control over, at least for the versions
> present in Debian sarge.
>
> I've been playing with various things, but I can't get MPL to compile
> unless I put #include <png.h> before #include "Python.h". I certainly
> don't consider myself a C include-file-order expert, so perhaps there's
> a way to avert this situation without reverting Jeff's patch.
>
> On the flipside, I went ahead and located several locations in the code
> where Python.h is included after system headers. I'm attaching a patch
> with the fruits of this labor. (Unfortunately, it also includes png.h
> before Python.h, because otherwise I can't get MPL to compile.) I'm not
> committing this because it seems like a rather significant change, and
> I'm not sure what it fixes other than more compiler warnings. And given
> Jeff's luck "fixing" compiler warnings, I'm not inclined to force this
> on anyone.
>
> In fact, I suggest simply reverting the changes in svn 2185 to
> src/_image.cpp, which, apart from a compiler warning, was apparently
> working just fine.
>
> [1] SF bug 1372239
> http://sourceforge.net/tracker/index.php?func=detail&aid=1372239&group_id=80706&atid=560720
> [2] Python/C API docs http://docs.python.org/api/includes.html
> [3] libpng's setjmp() redefinition
> http://lists.debian.org/debian-devel/2005/02/msg00892.html
>
> 
Andrew: Thanks - it seemed like a harmless change, but I should know 
better. I have libpng 1.2.8 on my MacOS X system and it worked fine - 
is that newer than the version you have?
-Jeff
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
NOAA/OAR/CDC R/CDC1 FAX : (303)497-6449
325 Broadway Web : http://www.cdc.noaa.gov/~jsw
Boulder, CO, USA 80305-3328 Office: Skaggs Research Cntr 1D-124

Andrew Straw wrote:
>On the flipside, I went ahead and located several locations in the code
>where Python.h is included after system headers. I'm attaching a patch
>with the fruits of this labor. (Unfortunately, it also includes png.h
>before Python.h, because otherwise I can't get MPL to compile.) I'm not
>committing this because it seems like a rather significant change, and
>I'm not sure what it fixes other than more compiler warnings. And given
>Jeff's luck "fixing" compiler warnings, I'm not inclined to force this
>on anyone.
>
Whoops, forgot the attachment. Here it is.

Taking John up on his offer to close some bugs, it looks like Jeff
closed SF bug 1372239[1], by moving the #include "Python.h" statement
ahead of the other includes.
As mentioned in the bug report, the "official" Python/C API docs[2]
state this is the correct behavior.
Unfortunately, on my Debian sarge amd64 system, this "fix" of a compiler
warning results in a compile error:
gcc: src/_image.cpp
In file included from /usr/include/png.h:363,
 from src/_image.cpp:6:
/usr/include/pngconf.h:310:2: #error png.h already includes setjmp.h
with some additional fixup.
In file included from /usr/include/png.h:363,
 from src/_image.cpp:6:
/usr/include/pngconf.h:310:2: #error png.h already includes setjmp.h
with some additional fixup.
error: Command "gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O3 -Wall
-Wstrict-prototypes -fPIC
-I/home/astraw/py2.3-linux-x86_64/lib/python2.3/site-packages/numpy-0.9.7.2243-py2.3-linux-x86_64.egg/numpy/core/include
-I/usr/local/include -I/usr/include -I. -Isrc -Iswig -Iagg23/include -I.
-I/usr/local/include -I/usr/include -I.
-I/home/astraw/py2.3-linux-x86_64/lib/python2.3/site-packages/numpy-0.9.7.2243-py2.3-linux-x86_64.egg/numpy/core/include/freetype2
-I/usr/local/include/freetype2 -I/usr/include/freetype2 -I./freetype2
-Isrc/freetype2 -Iswig/freetype2 -Iagg23/include/freetype2 -I./freetype2
-I/usr/local/include/freetype2 -I/usr/include/freetype2 -I./freetype2
-I/usr/include/python2.3 -c src/_image.cpp -o
build/temp.linux-x86_64-2.3/src/_image.o -DSCIPY=1" failed with exit
status 1
Googling on this indicates this libpng's setjmp() redefinition may be
responsible[3]. This looks like a real issue with Python.h and png.h and
not something we have much control over, at least for the versions
present in Debian sarge.
I've been playing with various things, but I can't get MPL to compile
unless I put #include <png.h> before #include "Python.h". I certainly
don't consider myself a C include-file-order expert, so perhaps there's
a way to avert this situation without reverting Jeff's patch.
On the flipside, I went ahead and located several locations in the code
where Python.h is included after system headers. I'm attaching a patch
with the fruits of this labor. (Unfortunately, it also includes png.h
before Python.h, because otherwise I can't get MPL to compile.) I'm not
committing this because it seems like a rather significant change, and
I'm not sure what it fixes other than more compiler warnings. And given
Jeff's luck "fixing" compiler warnings, I'm not inclined to force this
on anyone.
In fact, I suggest simply reverting the changes in svn 2185 to
src/_image.cpp, which, apart from a compiler warning, was apparently
working just fine.
[1] SF bug 1372239
http://sourceforge.net/tracker/index.php?func=detail&aid=1372239&group_id=80706&atid=560720
[2] Python/C API docs http://docs.python.org/api/includes.html
[3] libpng's setjmp() redefinition
http://lists.debian.org/debian-devel/2005/02/msg00892.html

Andrew,
I did not get as far as I would have liked this evening, but 
Axes.set_position() is now working again in svn, as is the colorbar.
I'm sorry for the disruption. This turned out to be more complicated 
than I thought.
To be continued...
Eric
Andrew Straw wrote:
> Eric Firing wrote:
> 
> 
>>John Hunter wrote:
>>
>>
>>>Eric, what is the status of the aspect code w/ respect to the presence
>>>of colorbars, or more generally, multiple axes? 
>>
>>
>>John,
>>
>>Broken! I assumed it would be OK, but now I see that is not the case.
>>I know why, and I can fix it easily on my next pass. But this does
>>highlight the question of more complex positioning situations.
> 
> 
> Hi Eric,
> 
> I don't know if you're aware of this, but Axes.set_position() seems to
> have broken in the last day or two, also.
> 
> Cheers!
> Andrew

On Monday 20 March 2006 10:02 pm, John Hunter wrote:
> We've fallen behind in the bugs, features and patches submitted to
> sourceforge. Over the last couple of days, after letting them
> languish for too long, I've managed to close about 10 or so feature
> requests and patches in the last few days. There are a lot of
> bug-reports yet to be dealt with.
>
> Some of these are trivial and take just a few minutes time. For
> example, I just closed the feature request to add a reversed colormap
> for grayscale. Jeff's recent contribution adds reversed colormaps for
> all colormaps so it was just a simple response pointing to cm.gray_r
>
> It would be a big help if any of you on the devel list could take a
> read through the latest bugs, features and patches and see if you know
> something about them. We are particularly behind on bug reports
>
> http://sourceforge.net/tracker/?group_id=80706&atid=560720
>
> with 50 some-odd open bugs. If you're on the devel list, try taking
> on one or a few of these. If not, but know enough matplotlib to
> answer these problems, let me know and I'll add you to the devel list
> so you can handle them.
I've closed quite a few myself over the last week. There seems to be plenty of 
low-hanging fruit.
Darren

We've fallen behind in the bugs, features and patches submitted to
sourceforge. Over the last couple of days, after letting them
languish for too long, I've managed to close about 10 or so feature
requests and patches in the last few days. There are a lot of
bug-reports yet to be dealt with.
Some of these are trivial and take just a few minutes time. For
example, I just closed the feature request to add a reversed colormap
for grayscale. Jeff's recent contribution adds reversed colormaps for
all colormaps so it was just a simple response pointing to cm.gray_r
It would be a big help if any of you on the devel list could take a
read through the latest bugs, features and patches and see if you know
something about them. We are particularly behind on bug reports
 http://sourceforge.net/tracker/?group_id=80706&atid=560720
with 50 some-odd open bugs. If you're on the devel list, try taking
on one or a few of these. If not, but know enough matplotlib to
answer these problems, let me know and I'll add you to the devel list
so you can handle them.
Thanks!
JDH

Darren Dale wrote:
....
> As of svn 2181, if you use a *Agg backend or the postscript backend with the 
> new API, the following script will yield a gap in the line, see attached. I 
> guess we need to decide if this is desireable behavior in general, I think it 
> is pretty useful myself.
Darren,
Yes, this is *very* desireable behavior. It should be in all backends. 
 If it were, then the masked array line plotting could take advantage 
of it, resulting in faster and simpler code. I can't think of any 
possible disadvantage to this behavior.
Thanks for doing it.
Eric

On Monday 20 March 2006 17:57, John Hunter wrote:
> >>>>> "Darren" == Darren Dale <dd...@co...> writes:
>
> Darren> I havent modified extension code before, and this change
> Darren> would affect all the *agg backends, so I dont want to
> Darren> commit before checking.
>
> Here is a quick checklist of things to consider before committing Agg
> changes
>
> 1) makes a plot that you can interact with
check
> 2) passes backend_driver.py screening for Agg
check
> 3) passes unit/memleak_hawaii3.py with no appreciable memory leak
Average memory consumed per loop: -0.1637k bytes (? thats odd.)
> 4) does something useful....
It helped me procrastinate, that's sort of useful.
> If it satisfies these, in my view it is suitable for public consumption.
As of svn 2181, if you use a *Agg backend or the postscript backend with the 
new API, the following script will yield a gap in the line, see attached. I 
guess we need to decide if this is desireable behavior in general, I think it 
is pretty useful myself.
a=arange(21, dtype='d')
a[10]=nan
plot(a, '-o')
savefig('nan_masked.png')

>>>>> "Darren" == Darren Dale <dd...@co...> writes:
 Darren> double lastx(-2.0), lasty(-2.0); @@ -1339,9 +1341,15 @@
 Darren> }
 Darren> catch (...) { moveto = true; + skippoint = true;
 Darren> continue;
 Darren> }
 Darren> - + else + if (MPL_isnan64(thisx) || MPL_isnan64(thisy)) {
 Darren> + moveto = true; + skippoint = true;
I don't think you need skippoint. A combination of setting "moveto"
with "continue" should suffice. continue implicitly skips the point,
and setting the moveto flag indicates to agg not to connect the
previous with the next point.
 catch (...) {
 moveto = true;
 continue;
 }
 else
 if (MPL_isnan64(thisx) || MPL_isnan64(thisy)) {
 moveto = true;
 continue;
 }
JDH

>>>>> "Darren" == Darren Dale <dd...@co...> writes:
 Darren> I havent modified extension code before, and this change
 Darren> would affect all the *agg backends, so I dont want to
 Darren> commit before checking.
Here is a quick checklist of things to consider before committing Agg changes
 1) makes a plot that you can interact with
 2) passes backend_driver.py screening for Agg
 3) passes unit/memleak_hawaii3.py with no appreciable memory leak
 4) does something useful....
If it satisfies these, in my view it is suitable for public consumption.
JDH

On Monday 20 March 2006 16:45, you wrote:
> Darren Dale wrote:
> >Thank you, Andrew (Baker's Dozen) Straw.
>
> Hey, stop thanking me! ;) Seriously, it's me who should be thanking you
> for all the work you're doing on the PS and latex fronts. I'm just glad
> I can do a couple of minor things to help you along the way.
>
> >Does this look about right?
> >
> >
> >def isnan(a):
> > return reshape(array([isnan64(i) for i in ravel(a)],'b'), shape(a))
>
> It looks fine to me -- it matches the behavior of numpy's isnan.
I modified _nc_imports.py and numerix/__init__.py. As of svn 2179, we have an 
isnan for every numerix flavor (numpy and numarray use their own). That means 
that the postscript backend can use nan's to mask points, if you use the new 
API.
I also found a way to patch _backend_agg.cpp to make it break lines around 
nan's. I havent modified extension code before, and this change would affect 
all the *agg backends, so I dont want to commit before checking. Here's the 
diff:
Index: src/_backend_agg.cpp
===================================================================
--- src/_backend_agg.cpp (revision 2178)
+++ src/_backend_agg.cpp (working copy)
@@ -23,6 +23,7 @@
 #include "_backend_agg.h"
 #include "_transforms.h"
 #include "mplutils.h"
+#include "MPL_isnan.h"
 #include "swig_runtime.h"
@@ -1324,6 +1325,7 @@
 double thisx, thisy;
 bool moveto = true;
+ bool skippoint = false;
 double heightd = height;
 double lastx(-2.0), lasty(-2.0);
@@ -1339,9 +1341,15 @@
 }
 catch (...) {
 moveto = true;
+ skippoint = true;
 continue;
 }
-
+ else
+ if (MPL_isnan64(thisx) || MPL_isnan64(thisy)) {
+ moveto = true;
+ skippoint = true;
+ }
+
 //use agg's transformer?
 xytrans.transform(&thisx, &thisy);
 thisy = heightd - thisy; //flipy
@@ -1367,8 +1375,9 @@
 path.move_to(thisx, thisy);
 else
 path.line_to(thisx, thisy);
-
- moveto = false;
+ if (!skippoint)
+ moveto = false;
+ skippoint = false;
 //std::cout << "draw lines " << thisx << " " << thisy << std::endl;
 }

Andrew Straw wrote:
> Eric Firing wrote:
> 
> 
>>John Hunter wrote:
>>
>>
>>>Eric, what is the status of the aspect code w/ respect to the presence
>>>of colorbars, or more generally, multiple axes? 
>>
>>
>>John,
>>
>>Broken! I assumed it would be OK, but now I see that is not the case.
>>I know why, and I can fix it easily on my next pass. But this does
>>highlight the question of more complex positioning situations.
> 
> 
> Hi Eric,
> 
> I don't know if you're aware of this, but Axes.set_position() seems to
> have broken in the last day or two, also.
> 
> Cheers!
> Andrew
Andrew,
Thanks--it makes sense that it would (and it is the reason for the 
colorbar problem), but I am embarrassed that I didn't spot it myself 
before committing changes.
Eric

Eric Firing wrote:
> John Hunter wrote:
>
>> Eric, what is the status of the aspect code w/ respect to the presence
>> of colorbars, or more generally, multiple axes? 
>
>
> John,
>
> Broken! I assumed it would be OK, but now I see that is not the case.
> I know why, and I can fix it easily on my next pass. But this does
> highlight the question of more complex positioning situations.
Hi Eric,
I don't know if you're aware of this, but Axes.set_position() seems to
have broken in the last day or two, also.
Cheers!
Andrew

Darren Dale wrote:
>Thank you, Andrew (Baker's Dozen) Straw.
> 
>
Hey, stop thanking me! ;) Seriously, it's me who should be thanking you
for all the work you're doing on the PS and latex fronts. I'm just glad
I can do a couple of minor things to help you along the way.
>Does this look about right?
> 
>
>def isnan(a):
> return reshape(array([isnan64(i) for i in ravel(a)],'b'), shape(a))
> 
>
It looks fine to me -- it matches the behavior of numpy's isnan.

On Monday 20 March 2006 13:40, Andrew Straw wrote:
> Darren Dale wrote:
> >Here's a bug: I need isnan to create my mask. It is provided by numerix
> > with numpy and numarray, but not Numeric. Can this be rectified?
>
> I just added the matplotlib._isnan extension module which is independent
> of the numerix choice (although I think it'll be better to stick with a
> numerix-given function, if available). Below is an example of its use.
> Perhaps you can modify the Numeric-flavor numerix so that isnan is
> exposed the same way as numarray and numpy -- I didn't do this because
> you'll be more familiar with the details than I am.
>
> #Example:
> import matplotlib._isnan as n
> import numpy
>
> for val in [3.2,3,numpy.nan,'adsf']:
> print 'val',val
> print n.isnan64(val)
> print
Thank you, Andrew (Baker's Dozen) Straw.
Does this look about right?
def isnan(a):
 return reshape(array([isnan64(i) for i in ravel(a)],'b'), shape(a))
In [1]: a=ones((3,3,3),'d')
In [2]: a[0,0,0]=array(0.0)/0
In [3]: isnan(a)
Out[3]:
[[[1,0,0,]
 [0,0,0,]
 [0,0,0,]]
 [[0,0,0,]
 [0,0,0,]
 [0,0,0,]]
 [[0,0,0,]
 [0,0,0,]
 [0,0,0,]]]

John Hunter wrote:
>>>>>>"Eric" == Eric Firing <ef...@ha...> writes:
> 
> Eric> be factored out. Resizing and repositioning are more
> Eric> generally useful; for example, they are used in the colorbar
> Eric> function. I would like to take a look at this broader
> Eric> question before finalizing the axes aspect ratio handling.
> 
> Eric, what is the status of the aspect code w/ respect to the presence
> of colorbars, or more generally, multiple axes? 
John,
Broken! I assumed it would be OK, but now I see that is not the case. 
I know why, and I can fix it easily on my next pass. But this does 
highlight the question of more complex positioning situations.
Eric

John Hunter wrote:
>>>>>>"Eric" == Eric Firing <ef...@ha...> writes:
> 
> 
> >> The set_aspect function is called from axis() in pylab.py and I
> >> think somewhere in backend_basics after a zoom event.
> 
> Eric> Thanks for pointing that out--I thought I had found
> Eric> everything, but I certainly had not. I will take a look at
> Eric> those calls; at the least, they will need to be changed
> Eric> slightly if I remove the fixLimits kwarg.
> 
> One of the drawbacks of having pass through kwargs. grep isn't as
> useful as you'd like it to be. This is a docstring bug in pylab.axis,
> which should be updated to reflect the fixLimits kwarg (if it survives
> the refactor).
> 
> JDH
John,
Yes, I will try to check all relevant docstrings on my next pass--this 
evening, if all goes well.
At least some of the things I missed were greppable; I just didn't spend 
enough time to check everything carefully.
Eric

>>>>> "Eric" == Eric Firing <ef...@ha...> writes:
 Eric> be factored out. Resizing and repositioning are more
 Eric> generally useful; for example, they are used in the colorbar
 Eric> function. I would like to take a look at this broader
 Eric> question before finalizing the axes aspect ratio handling.
Eric, what is the status of the aspect code w/ respect to the presence
of colorbars, or more generally, multiple axes? 
JDH