[Numpy-discussion] Numeric3

[Gary Strangman]

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 
> MATLAB-like?

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

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

-best
Gary