Should numpy.sqrt(-1) return 1j rather than nan?

[Fernando Perez]

On 10/12/06, Travis Oliphant <oliphant.travis at ieee.org> 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