|
From: John H. <jdh...@ac...> - 2004-05-14 12:58:15
|
The new transformation module I've been working on is implemented in
extension code. It offers a couple of important benefits, namely
speed and generality (affines, nonseparable xy transformations). It's
not in CVS yet because I'm still ironing out the details.
I have two methods for operating over sequences of x and y, seq_x_y
and numerix_x_y. The first uses the python sequence API and the
second uses the numerix api. I expect the latter will be a good bit
faster for long lines, since it doesn't have the python object type
coercion to deal with, but I haven't profiled it.
But there is a gotcha. When I compile the code, I use flag in
setup.py to indicate whether to compile with Numeric or numarray.
This sets a flag and that is used in the transforms module (and the
image module) that will import arrayobject.h from either Numeric or
numarray.
A problem can arise if someone compiles with one and uses a different
setting in ~/.matplotlibrc. I compiled the module with Numeric but
used numarray in my matplotlibrc. The transformation went fine,
presumably thanks to the numarray compatibility layer. I passed the
transformed arrays off to one of the backends, which does
from matplotlib.numerix import Int16
y = int(self.height) - y.astype(Int16)
and got a
ValueError: type must be either a 1-length string, or python type
object
clearly because of the difference between numpy and numarray type
args.
Is there a clever workaround for this problem? It doesn't affect any
of the agg or PS backends. GTK and GD both need to convert their
arrays to ints before passing them on to their respective renderers.
One solution is to do the conversion in list comps
y = [ int(self.height-val) for val in y]
which obviously implies a performance hit but probably a bearable one
given the other speedups that the new transformation module implies
and that users have an option to use GTKAgg instead of GTK and Agg
instead of GD for optimal performance.
Another question is win32, where the user doesn't have the choice at
compile time. If we compile in numpy for win32, the user's numarrays
will be transformed into numpys at render time, but this won't affect
the user arrays (unlike in scipy where the user is getting the return
values) so I don't see it as a big deal. I think trying to compile in
both or supplying alternate binaries is doable but may not be worth
the maintenance and complexity.
In any case, there are a couple of readers here who know a bit more
about numarray and numeric than I do <wink> ; any thoughts?
JDH
|