On 2006-05-27, Grant Edwards <[EMAIL PROTECTED]> wrote:
> I found another module that claims to do what I want
>
> http://www.cdc.noaa.gov/people/jeffrey.s.whitaker/python/griddata.html
>
> But, no matter what data I pass, I get either all zeros or all
> NaNs back. :/
Aaarrrggh. After some more sweating and swearing, it looks like
both the griddata module and the scipy.delaunay.nn_interpolator
do work as long as you pass the preferred brand of arrays to
them and specify the mesh/grid using the right scheme.
My problems seem to have been caused by the interaction of a
number of factors:
1) Gnuplot.py seems to like convert _some_ floating-point
arrays to integer values before plotting them -- this only
seems to happen when passing 2D arrays to splot(). That
was breaking some of my data.
2) Converting the arrays to nested lists prevents the rounding
to an integer problem but it apparently transposed the x/y
axis without my noticing. Then the "holes" in some of the
interpolated surfaces showed up. It turns out there were
NaNs in the input data that were causing the holes, but
because of the transposed x/y axis, I was looking in the
wrong place in the data.
3) Attempting to use the griddata module resulted in mixing
array objects from pylab, numpy, numeric, and scipy (some
of which may or may not be the same -- I can't keep track).
Mixing array types seems to have tripped up some
extensions. AFAICT, python code is happy with any of the
array types since they're pretty much the same if you go by
"duck" typing. But C/Fortran extensions only seem to work
with one sort or the other, and some python modules that
wrap those extensions will pass anything that quacks on
down to C/Fortran code, when then gets confused. Maybe.
4) Even when the arrays were OK, there are a couple
incompatible ways to specify a mesh/grid, and I picked the
wrong one in at least one case.
--
Grant Edwards grante Yow! MMM-MM!! So THIS is
at BIO-NEBULATION!
visi.com
--
http://mail.python.org/mailman/listinfo/python-list
