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 |