strang at nmr.mgh.harvard.edu
Tue Feb 8 06:57:32 CST 2005
On Mon, 7 Feb 2005, Travis Oliphant wrote:
>> And NOT a matlab-like environment? Or is it trying to be both?
> Very loosely a matlab or IDL-like environment. Nobody has really defined
> what it means to be a MATLAB-like environment. The idea is that someone
> could do what one can do in MATLAB or IDL, not write code in exactly the same
> way. A MATLAB translator is an entirely different project.
> So, I'm not sure. There is no requirement that contributions "not be
> classed based", or conform to some command in MATLAB.
> Perhaps what you are referring to is the fact that
> from scipy import *
> makes a lot of command-like interaction possible. Is this seen as
I was focusing on the word "environment". The current Matlab "environment"
is heavily graphical and includes separate panels for command history,
defined variables (along with their memory requirements), a command
window, etc. Of course it also has a flat namespace. The python
interpreter is already its own (restricted) environment, and Idle is
another. Building a Matlab "environment", in this sense of the word, is a
major undertaking and should be a separate goal (and, IMHO, probably not
all that useful). Doesn't sound like that's what you meant. My
> I guess right now, scipy is trying to bring lots of modules under a common
> naming convention.
And this is great. I'd definitely use such a creature. However, it sounds
like several folks would also appreciate (myself included) access to
individual modules (or smaller subsets of interdependent modules) because
of installation troubles. I'm probably not the one to ask about how to
divvy those up, but perhaps it would be useful to have a "requires
fortran" group. And a python-only group. And a python-plus-C group. That
way, users (or "mini-developers") could pick their installation battles
(on windoze, having ANY compiler can be a significant $$ or installation
problem). This would make it more transparent as to which routines are
well-tested and fast (most Fortran-based code), fast (C and Fortran), or
easy-to-modify (Python pieces). The transparency could also guide folks
who can/do write C/Fortran code to translate their favorite python-only
pieces to a faster format. Just a thought. ('course, those dividing lines
may not make for nice module names ... sigh.)
> I think the goals of scipy are very much what people are talking about here.
> SciPy ultimately becomes what its users and developers want it to become.
> That is why I'm so unclear as to why we have not received more support in its
> development --- even in the way of ideas as to how to make it better ---
> until the great ideas that have been suggested on this list recently.
Perhaps because SciPy has seemed monolithic, rather than a collection of
largely independent modules. That's how I've perceived it, and I even have
a module inside SciPy. ;-) I think that making pieces available (groupings
of interdependent modules) in addition to everything-under-the-sun would
help with that perception.
More information about the Numpy-discussion