[Numpy-discussion] Happy New Year Nummies -- and some discussion about the future

[Paul F. D. <pau...@ho...>]

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

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.

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.

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. 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. 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".)

Best regards to all,

Paul Dubois