[SciPy-user] NumPy vs. SciPy and other speed comparisons

Johann Cohen-Tanugi cohen@slac.stanford....
Wed Jun 11 04:31:11 CDT 2008


FWIW:

In [28]: numpy.complex(0,1)**2
Out[28]: (-1+0j)

In [29]: numpy.sqrt(numpy.complex(0,1)**2)
Out[29]: (0.0+1.0j)

In [30]: numpy.sqrt(-1)
Out[30]: nan

So numpy knows about complex, but numpy.sqrt does not cast -1 into a 
complex number. Beyond Gael's valid statement about namespacing,
I find this slightly surprising and maybe even a tad inconsistent, but I 
will certainly not fight a war over it :)
JCT

Robert Kern wrote:
> On Wed, Jun 11, 2008 at 03:55, Gael Varoquaux
> <gael.varoquaux@normalesup.org> wrote:
>   
>> On Wed, Jun 11, 2008 at 10:50:14AM +0200, Sebastian Haase wrote:
>>     
>>> Not to say that this is scary, that two functions, same name, give
>>> different results ....
>>>       
>> I don't agree. That's why you have namespaces. numpy.sum and
>> __builtin__.sum don't give the same results, and I find that expected.
>>     
>
> While I don't *particularly* want to open this can of worms again, the
> power of the Internet compels me. To my mind, the big fault with the
> current arrangement is not that two functions with the same name have
> different functionality, but that scipy.* is *almost* the same
> namespace as numpy.* without any clear signposts as to the
> differences. It's one thing to have the single common name between
> numpy.* and __builtin__.* have different functions in each namespace.
> It's another to say that 9 of 489 common names do.
>
> For what it's worth, the "scipy versions" of the 9 functions are all
> exposed from numpy.lib.scimath.
>
> What really annoys me is that "from scipy import *" imports all of the
> subpackages. Again. I don't know how many times I thought I removed
> that nonsense, but like a bloody vampire, it just ... keeps ... coming
> ... back.
>
>   


More information about the SciPy-user mailing list