[Numpy-discussion] Hello and my first patch

[Christopher Barker]

The situation is confusing, we all know that, and we all want to move 
toward a better way.

Key to that is that SciPy needs to be easier to build and install -- 
that's happening, but I don't know that it's there yet. Maybe it can be 
built on Fedora Core 4 now, but last I tried it couldn't be.

Anyway, few thoughts on comments made here:

> Matplotlib plots the spectrogram

Here's a key problem -- matplotlib includes WAY too much. There are 
reasons, and there is history, but as a goal, I think matplotlib should 
be just what it says it is -- a plotting library.

I don't know that MPL has been declared the "official" plotting package 
for SciPy, but it would be nice if it were. SciPy has suffered for a 
very long time without a full-featured, cross-platform, "official" 
plotting package. AS far as I know, MPL comes the closest (except it 
doesn't do 3-d -- darn!)

A. M. Archibald wrote:
> Frankly, I tend to prefer the other approach to solving all these
> issues: distribute numpy, scipy, and matplotlib as one bundle.

This is really the only way to set things up for someone that want what 
could be used as a "matlab replacement". If we ever get settools working 
just right, we should be able to do:

easy_install scipy

and have it all! woo hoo!

However, as we work to that goal, i do think it makes sense that numpy, 
and matplotlib be packages unto themselves -- developed separately, etc. 
In fact, SciPy should be a collection of distinct packages as well. I 
think there is a real benefit to be able to install just what you need. 
Not very user of numpy and/or MPL is looking for a full scientific 
software package.

I'm a big advocate of people using numpy arrays for all sorts of thinks 
that fit well into an n-d array, that have nothing to do with Scientific 
programming. Matplotlib is also very useful for people who need a quick 
plot for a web site or something. These people don't want to install the 
entirety of SciPy.

> * routines and objects can be in the package in which they make the
> most semantic sense,

exactly. If it's plotting (but not computing stuff to plot) put it in 
MPL, if it's generic computation (if you can't understand it with high 
school math, it's not generic), put it in numpy. Of course, these aren't 
clear definitions, but can still be useful as guidelines.


> * documentation can be cross-referenced between packages (so the
> Matrix class can tell people to look in scipy.linalg for inverses, for
> example)

If it were me, I'd probably have the Matrix package depend on a linear 
algebra package, and have only one of those.



Travis Oliphant wrote:

> 3) some kind of problem-domain hierarchy

+1

> Do we want to pull scipy apart  into two components:  one that needs 
> Fortran to build and another that doesn't? 

yup -- I don't like it, but the state of Fortran compilers really gives 
little choice.



-Chris








-- 
Christopher Barker, Ph.D.
Oceanographer
                                     		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov