[Numpy-discussion] Numeric3

Peter Verveer verveer at embl.de
Sun Feb 6 08:56:24 EST 2005

On Feb 6, 2005, at 5:41 PM, konrad.hinsen at laposte.net wrote:

> On 06.02.2005, at 01:06, Travis Oliphant wrote:
>> But MATLAB is a huge package.  SciPy has been trying to do the same 
>> thing.  Plotting was needed and matplotlib did a great thing in 
>> providing excellent plotting.  I've never understood the reason for 
>> matplotlib to remain separate except as evidence of the great schism 
>> that was occuring in the community.
>> In fact, when Eric and I began scipy, I wanted to call it pylab 
>> (you'll notice I have the pylab.sourceforge.net site).  I have fond 
>> ties to MATLAB myself.
> That's actually one of the non-technical issues I have with SciPy. 
> SciPy "smells" like Matlab. Which is fine for those who know and like 
> Matlab, but not for those (like me) who find Matlab rather 
> incompatible with their brains. SciPy, like Matlab, is based on the 
> principle that all operations should be expressed in terms of arrays. 
> My personal approach is that operations should be expressed in terms 
> of problem-specific classes in which the internal use of arrays is an 
> implementation detail.
> There are arguments for and against both approaches, and I think there 
> is space (meme space) for both. I just mention this to point out that 
> I don't expect SciPy to become the one and only scientific Python 
> library that includes everything. I don't expect to contribute code to 
> SciPy, for example. I wouldn't mind using it, of course, in the 
> implementation of my classes, if and when the installation issues 
> become less of a problem.

That more or less sums up my approach too. I tend to program in a mix 
of these two approaches.

I also think there is space for both approaches. But when code goes 
into a matlab-like package it may become less accessible to people who 
prefer to work in the more programming oriented style. The other way 
around is better: if it is accessible to all in the form of a more or 
less independent package, it can be used for both approaches. This is 
why I am also not going to program specifically for SciPy, but I would 
program my packages to be 'scipy-ready' if that is made easy...


More information about the NumPy-Discussion mailing list