[SciPy-dev] Re: [Numpy-discussion] Numeric3

[Travis Oliphant]

Gary Strangman wrote:

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

I think that a basic install should always include linear algebra, 
random numbers, and fft code.  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.  That 
is essentially what scipy is trying to be -- a place for these extras 
and additional numeric routines to live.   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(++). 

> problem (thanks!!). John indicates that the ultimate goal with 
> matplotlib is to provide plotting, not just scientific plotting, which 
> is even better! In that case, though, and in keeping with my previous 
> comment, perhaps the name matplotlib is a little misleading 
> (suggesting scientific plotting only). Again, if I were familiar with 
> python but just starting timeseries analysis, I would expect to load 
> my data into a (multiarray) python object, import timeseries.py, 
> import plotlib.py (i.e., matplotlib) and go to work doing timeseries 
> analysis ... be that at LLNL, Wall St, or in my neuro lab.

I think matplotlib is great.   SciPy's plotting methods were always 
considered stop-gap (functional but not much else).   I would have much 
rather seen matplotlib integrate in with the scipy effort, though.   
Perhaps these modularity issues would be solved already, had this been 
attempted from the start.

-Travis