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
[EMAIL PROTECTED]
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Numpy-discussion mailing list
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion
