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

Stefan van der Walt stefan at sun.ac.za
Wed Oct 11 20:17:27 EDT 2006


On Wed, Oct 11, 2006 at 05:21:44PM -0600, Travis Oliphant wrote:
> Stefan van der Walt wrote:
> 
> >I agree with Fernando on this one.
> >
> >Further, if I understand correctly, changing sqrt and power to give
> >the right answer by default will slow things down somewhat.  But is it
> >worth sacrificing intuitive usage for speed?
> >  
> >
> For NumPy, yes. 
> 
> This is one reason that NumPy by itself is not a MATLAB
> replacement. 

Intuitive usage is hopefully not a MATLAB-only feature.

> >N.power(2,-2) == 0
> >
> >and
> >
> >N.sqrt(-1) == nan
> >
> >just doesn't feel right.  
> >
> 
> Only because your expectations are that NumPy *be* a MATLAB 
> replacement.  The problem is that it sacrifices too much for that to be 
> the case.   And we all realize that NumPy needs more stuff added to it 
> to be like IDL/MATLAB such as SciPy, Matplotlib, IPython, etc.

I have none such expectations -- I havn't used MATLAB in over 5 years.
All I'm saying is that, since the value of the square-root of -1 is
not nan and 2^(-2) is not 0, it doesn't surprise me that this
behaviour confuses people.

> The "intuitive" functions (which must do argument checking) are (in 
> numpy.lib.scimath) but exported as
> 
> scipy.power (actually I need to check that one...)
> scipy.sqrt
> 
> What could be simpler?  ;-)

I'm sure this is going to come back and haunt us.  We have two
libraries, one depends on and exposes the API of the other, yet it
also overrides some functions with its own behaviour, while keeping
the same names.

I'll shut up now :)

Cheers
Stéfan

-------------------------------------------------------------------------
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