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

[Travis Oliphant]

> 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