[SciPy-user] Arrayfns in numpy?

Fernando Perez fperez.net@gmail....
Wed Mar 7 01:46:36 CST 2007

On 3/7/07, Travis Oliphant <oliphant@ee.byu.edu> wrote:
> > -100
> >
> > I am strongly opposed to mixing computations into NumPY.  Why is 1-d
> > interpolation good to have inside of NumPy? why not nd-interpolation?
> > why not fft? or SVD? or some linear algebra thing?
> >
> I agree with the idea of the statement.  However, practicality may beat
> purity here because of the backward-compatibility issue.  The only
> proposal on the table is pulling in more functions from arrayfns.   I'm
> fine if they live in the oldnumeric name-space (but it will actually be
> easier to put them in the lib namespace because the arrayfnsmodule.c
> file became the _compiled_base.c file in numpy.lib.
> Perhaps they can still live in _compiled_base.c  but not be pulled in to
> numpy.lib (only a  oldnumeric.arrayfns module).

-1.  If they are going to go in, make them first-class citizens.

For better or worse, there are functional units in numpy that go
beyond pure array basics: linalg, fft are the leading examples.   Not
putting these in would break so much old Numeric code that it really
would have been unacceptable.  So if the argument for the
interpolation stuff is the same, then it should go also as part of

IMO, oldnumeric is a way to keep the old *APIs* for things that can be
done differently (often better) in numpy, as a way of easing the
transition of old codes.

But if you put interpolation in oldnumeric, then /everyone/ who wants
interpolation and doesn't have scipy around is going to pull
oldnumeric in.  And that will have the unintended side effect of
basically promoting oldnumeric as a first-class API rather than a
backwards-compatibility layer for codes that haven't been properly



More information about the SciPy-user mailing list