[SciPy-dev] Re: [Numpy-discussion] Numeric3

Travis Oliphant oliphant at ee.byu.edu
Mon Feb 7 13:59:53 CST 2005


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.

I think I understand better what Konrad is saying than I did several 
years ago.   SciPy may have started with the idea of being something 
like MATLAB, but in fact, scipy has lot's of class-based approaches:  
polynomials, random variables, gridding, ode solvers, just to name a few.

Basically, scipy just wants code that works and can be useful to 
others.  I don't think you'll find that scipy is opposed to class-based 
solutions at all.   We do tend to like names that are shorter (or at 
least aliases that are shorter, so that command-line interactive use is 
easier). 

Now, I think of scipy really just as a gathering place for Numerical 
algorithms.  I think it is clear that scipy needs to work on it's 
modularity, taking into account some of the great comments that have 
been made on this list if it is to be what it is intended to be.

-Travis










>
> 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.
>
> Konrad.
> -- 
> ------------------------------------------------------------------------ 
> -------
> Konrad Hinsen
> Laboratoire Leon Brillouin, CEA Saclay,
> 91191 Gif-sur-Yvette Cedex, France
> Tel.: +33-1 69 08 79 25
> Fax: +33-1 69 08 82 61
> E-Mail: khinsen at cea.fr
> ------------------------------------------------------------------------ 
> -------
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
> Tool for open source databases. Create drag-&-drop reports. Save time
> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
> Download a FREE copy at http://www.intelliview.com/go/osdn_nl
> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion





More information about the Scipy-dev mailing list