[Numpy-discussion] Re: Numpy-discussion digest, Vol 1 #152 - 2 msgs

[Travis Oliphant]

> 
> A millenium-end report from the Head Nummie (this name is a joke; see the
> DEVELOPERS file):
> 

Our nummie-ears are listening....

> There have been a steady set of messages on the subject of I should do this
> or that to make it easier to make RPMs.  It is impossible for me to act on
> these: I don't know much about RPMs, and if I did, I don't know if making
> the change suggested is good or bad for someone doing something else, like
> making Windows installers. 


> Therefore my policy is to rely on the Distutils
> people to work this out. Those who wish to make it easier to make a binary
> installer for platform xyz should figure out what would be required by the
> Distutils bdist family of commands.

Good idea to go with the distutils for doing this.  I've delayed RPM's for
this reason until I figure out how to interact with the distutils better
(I haven't spent much time doing it yet).

> 
> That is not to say that I don't appreciate people trying to help. I'm
> grateful for all the support I get from the community. I think that relying
> on division of labor in this case is the right thing to do, so that we take
> advantage of the Distutils effort. If I'm wrong, I'll listen.
> 
> There are a number of bug reports on the sourceforge site. I would be
> grateful for patches. In particular there are two reports dealing with FFTs.
> I lack the expertise to deal with these.

I'll look into these unless somebody has them done.

> 
> The masked array package MA has been getting more of a workout as I put it
> into production at my site. I believe that it fills not only the immediate
> need for dealing with missing values, but can serve as a model for how to
> make a "Numeric-workalike" with extra properties, since we can't inherit
> from Numeric's array. Since MA is improved fairly often, I recommend keeping
> up via cvs if you are a user.
> 
> I have new manuals but have had difficulty with the transport up to
> SourceForge. Anybody else having such a problem? I used scp from a Linux box
> and it sat there and didn't do anything.
> 
> The rest of this is for developers.
> 
> Actually, once you get into it, it isn't all that clear that inheritance
> would help very much. For example, suppose you want an array class F that
> has masked values but also has a special behavior f() controlled by a
> parameter set at creation, beta. Suppose therefore you decide to inherit
> from class MA. Thus the constructor of your new class must take the same
> arguments as an MA array but add a beta=somedefault. OK, we do that. Now we
> can construct a couple of F's:
> f1 = F([1.,2.,3.], beta=1.)
> f2 = F([4.,2.,1.], beta=2.)
> Great. Now we can do f1.f(), f2.f(). Maybe we redefine __str__ so we can
> print beta when we print f1.
> 
> Now try to do something. Anything. Say,
> f3 = f1 + f2
> 
> Oops. f3 is an MA, not an F. We might have written __add__ in MA so the it
> used self.__class__ to construct the answer. But since the constructor now
> needs a new parameter, there is no way MA.__add__ can make an F. It doesn't
> know how. Doesn't know how to call F(), doesn't know what value to use for
> beta anyway.
> 

> So now we redefine all the methods in MA. Besides muttering that maybe
> inheriting didn't buy me a lot, I am still nowhere, for the next thing I
> realize is that every function f(a) that takes an MA as an argument and
> returns an MA, still returns an MA. If any of these make sense for an
> instance of F, I have to replace them, just as MA replaced sin, cos, sqrt,
> take, etc. from Numeric.
> 
> I have therefore come to the conclusion that we have been barking up the
> wrong tree. There might be a few cases where inheritance would buy you
> something, but essentially Numeric and MA are useless as parents. Instead,
> what would be good to have is a python class Numeric built upon a suite of C
> routines that did all the real work, such as adding, transposing, iterating
> over elements, applying a function to each element, etc. 

I think this is what I've been trying to do in the "rewrite."  Paul
Barrett has made some excellent progress here.

> Since it is now
> possible to build a Python class with C methods, which it was not when
> Numeric was created, we ought to think about it. 

What does this mean?  What feature gives this ability?  I'm not sure I see
when this changed?


> Such an API could be used
> to make other classes with good performance. We could lose the artificial
> layer that is in there now that makes it so tedious to add a function. (I
> counted something like five or six places I had to modify when I added
> "put".)

I'd love to talk more with you about this.

I'm now at my new place for anyone wishing to contact me.

Travis Oliphant
437 CB
Brigham Young University
Provo, UT  84602
oliphant at ee.byu.edu

(801) 378-3108

Thanks for you great efforts Paul.