(Very) well said, Fernando. Thanks!
DG
Fernando Perez wrote:
> On 10/12/06, Travis Oliphant <[EMAIL PROTECTED]> wrote:
>
>
>> Why in the world does it scare you away. This makes no sense to me.
>> If you don't like the scipy version don't use it. NumPy and SciPy are
>> not the same thing.
>>
>
> I'd like to pitch in (again) on this issue, but I'll try to make sure
> that it's clear that I'm NOT arguing about sqrt() in particular, one
> way or another.
>
> It's perfectly clear that numpy != scipy to all of us. And yet, I
> think it is equally clear that the two are /very/ tightly related.
> Scipy builds on top of numpy and it directly exposes a LOT of the
> numpy API as scipy functions:
>
> In [21]: import numpy as n, scipy as s
>
> In [22]: common_names = set(dir(n)) & set(dir(s))
>
> In [23]: [getattr(n,x) is getattr(s,x) for x in common_names ].count(True)
> Out[23]: 450
>
> In [24]: len(common_names)
> Out[24]: 462
>
> That's 450 objects from numpy which are directly exposed in Scipy,
> while only 12 names are in both top-level namespaces and yet are
> different objects. Put another way, scipy is a direct wrap of 97% of
> the numpy top-level namespace. While /we/ know they are distinct
> entities, to the casual user a 97% match looks pretty close to being
> the same, especially when the non-identical things are all
> non-numerical:
>
> In [27]: [x for x in common_names if getattr(n,x) is not getattr(s,x)]
> Out[27]:
> ['pkgload',
> 'version',
> '__config__',
> '__file__',
> '__all__',
> '__doc__',
> 'show_config',
> '__version__',
> '__path__',
> '__name__',
> 'info',
> 'test']
>
> In [32]: n.__version__,s.__version__
> Out[32]: ('1.0.dev3306', '0.5.2.dev2252')
>
> Basically, at least for these versions, the top-level API of scipy is
> a strict superset of the numpy one for all practical purposes.
>
> I think it's fair to say that if we start sprinkling special cases
> where certain objects happen to have the same name but produce
> different results for the same inputs, confusion will arise.
>
> Please note that I see a valid reason for scipy.foo != numpy.foo when
> the scipy version uses code with extra features, is faster, has
> additional options, etc. But as I said in a previous message, I think
> that /for the same input/, we should really try to satisfy that
>
> numpy.foo(x) == scipy.foo(x) (which is NOT the same as 'numpy.foo is
> scipy.foo')
>
> within reason. Obviously the scipy version may succeed where the
> numpy one fails due to better algorithms, or be faster, etc. I'm
> talking about a general principle here.
>
> I doubt I'll be able to state my point with any more clarity, so I'll
> stop now. But I really believe that this particular aspect of
> consistency between numpy and scipy is a /very/ important one for its
> adoption in wider communities.
>
> Best,
>
> f
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Numpy-discussion mailing list
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion
