[Numpy-discussion] Numeric3

[Gary Strangman]

>> To be in keeping with other python objects, it seems this object would 
>> need to be tight, fast and easily extensible. I *think* this is exactly 
>> what Numeric3 is intended to do. Getting this right is tricky, but it 
>> seems like current solutions are EXTREMELY close.
>
> I think it's close too, that's why I'm willing to do this, right now.

:-)

>> already exists. Granted, the notion of what's "basic" vs. advanced is 
>> relative (e.g., where do you put fft, or linear_algebra?). But if made 
>> modular and encapsulated (e.g., an fft.py, linear_algebra.py, 
>> integration.py, morphology.py) and made available both individually and as 
>> part of one or more suites--see #4 below, it's easier to build on existing 
>> code rather than reinvent.
>
> There seems to be several users on this list that agree.  I would agree too, 
> but would also state that Python also has the idea of "batteries included" 
> meaning that the html, cgi, and xml libraries are all installed using a 
> common installer.   SciPy has tried to be modular, too but have a common 
> installer.  SciPy is an umbrella package with several sub-packages. 
> Sometimes it is hard to be modular when a sub-package depends on linear 
> algebra routines for example.

The "batteries included" is a good point. But I guess I'm not alone in 
the modularity argument.

> I think that a basic install should always include linear algebra, random 
> numbers, and fft code.

+1

> I don't think this should live under a Numeric 
> package because if we are to get arrayobjects into the core, then we need to 
> develop some other place for these things to live.

+1

> That is essentially what 
> scipy is trying to be -- a place for these extras and additional numeric 
> routines to live.

And NOT a matlab-like environment? Or is it trying to be both?

>   Perhaps we underestimated the problems with using FORTRAN 
> (but I still don't think so given that g77 is available wherever gcc is). 
> With f2py, FORTRAN is incredibly quick to develop Python modules with.  So, I 
> would have a hard time saying that we should not use FORTRAN.  I can conceed 
> that we should separate modules that need FORTRAN from those that need only 
> C(++).

Being able to say, "to get these additional functions, you need to get 
FORTRAN" would be fantastic. It would help folks (including myself, who 
dreads complicated installs) if wrestling with the install is going to be 
worth the effort.

Gary