Should numpy.sqrt(-1) return 1j rather than nan?
Travis Oliphant
oliphant.travis at ieee.org
Thu Oct 12 02:32:17 CDT 2006
> 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.
>
Fernando,
I don't disagree with you in principle. I don't think anybody does. I
think we should try to keep the interfaces and expectations of scipy and
numpy the same.
Unfortunately, we have competing issues in this particular case (in the
case of the functions in numpy.lib.scimath). Nobody has suggested an
alternative to the current situation in SVN that is satsifying to enough
users.
Here is the situation.
1) NumPy ufuncs never up-cast to complex numbers without the user
explicitly requesting it so sqrt(-1) creates a floating-point error
condition which is either caught or ignored according to the user's
desires. To get complex results from sqrt you have put in complex
numbers to begin with. That's inherent in the way ufuncs work.
This is long-standing behavior that has good reasons for it's
existence. I don't see this changing. That's why I suggested to move
the discussion over to scipy (we have the fancy functions in NumPy, they
are just not in the top-level name-space).
Now, it would be possible to give ufuncs a dtype keyword argument that
allowed you to specify which underlying loop was to be used for the
calculation. That way you wouldn't have to convert inputs to complex
numbers before calling the ufunc, but could let the ufunc do it in
chunks during the loop. That is certainly a reasonable enhancement:
sqrt(a, dtype=complex).
This no-doubt has a "library-ish"-feeling, but that is what NumPy is.
If such a change is desireable, I don't think it would be much to
implement it.
2) In SciPy 0.3.2 the top-level math functions were overloaded with
these fancy argument-checking versions. So that scipy.sqrt(-1) would
return 1j. This was done precisely to attract users like David G. who
don't mind data-type conversions on the fly, but prefer automatic
conversion (funny being called non-sensical when I was the one who wrote
those original scipy functions --- I guess I'm schizophrenic).
We changed this in SciPy 0.5.1 by accident without any discussion. It
was simply a by-product of moving scipy_base (including those
special-handling functions) into NumPy and forgetting to import those
functions again into top-level SciPy. It was an oversight that caused
backwards compatibilty issues. So, I simply changed it back to what
SciPy used to be in SVN.
If we want to change SciPy, then fine, but let's move that discussion
over to scipy-dev.
In short, I appreciate all the comments and the differences of opinion
they point out, but they are ultimately non-productive. We can't just
change top-level sqrt to be the fancy function willy-nilly. Paul says
I'm nice (he's not talked to my children recently), but I'm not that
much of a push-over. There are very good reasons that NumPy has the
behavior it does.
In addition, the fancy functions are already there in numpy in
numpy.lib.scimath. So, use them from there if you like them. Create
your own little mynumpy module that does
from numpy import *
from numpy.lib.scimath import *
and have a ball. Python is flexible enough that the sky is not going to
fall if the library doesn't do things exactly the way you would do it.
We can still cooperate in areas that we agree on.
Again. Put this to rest on NumPy and move the discussion over to scipy-dev.
-Travis
-------------------------------------------------------------------------
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
More information about the Numpy-discussion
mailing list