Travis E. Oliphant wrote:
> I think a numpy-ism crept into the code-base (not that I particularly
> mind as I will welcome the day matplotlib jettisons it's 3-array support).
So will I! I don't have John's saintly patience, although I understand
his rationale. My error in this case was failing to test a change I
made with all three packages, although I try to do that whenever I think
there might be a problem.
>
> In quiver.py, nx.nan is attempted, which raises an error, unless I'm
> missing the definition of nan somewhere.
Well, it was working at least with the version of numpy I had when I
made the change in quiver to use nan internally as a mechanism for
supporting masked array input. I have updated to svn, and it works with
your change of course, so all is well. I added nan definitions for
Numeric and numarray which work on my linux box, but I have not tested
them on other platforms; I guess in the worst case, if it doesn't work
on Mac or Windows I will have to change quiver.py to use masked arrays
internally instead of nans. (The definition I used is "nan =
float('nan')".) I used nan here because it considerably simplifies the
code, now that nan is supported in the primary backends.
Eric
|
