Re: [Matplotlib-users] numerix on win32

[Todd M. <jm...@st...>]

On Fri, 2004-05-14 at 08:35, John Hunter wrote:
> 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.

Yeah.  numarray has full blown type objects which form a hierarchy which
can be used to test for type properties such as signed, integral, etc. 

numarray uses names for its type objects that were used by Numeric to
make 1 character typecodes clearer and easier to remember.  Thus, in
numarray Int16 is an object, but in Numeric Int16 is an alias for 's'.

Over time,  our compatibility ambitions have grown so now numarray
generally works with Numeric typecodes wherever a type object is
expected.  

So,  while this feels like walking backward,  you can say:

        y = int(self.height) - y.astype('s')

and expect it to work with either.

> 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?

(1) One thought I've had for handling this has been to improve the basic
binary compatibility of numarray with Numeric to the point that numerix
can be extended to the C-level.  In this scheme,  an extension would be
compiled against neither numarray nor Numeric but against numerix; 
which array package was actually being used would be figured out at run
time much as it works at the Python level now.   I'm still exploring the
idea.

(2) I could just build a numarray version of the matplotlob installer
with each release.  That would offload the work from you and would keep
the matplotlib code cleaner.  

Todd