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

[Tim Hochberg]

Travis Oliphant wrote:
> Travis Oliphant wrote:
>   
>> 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.
>>
>>   
>>     
> This could be implemented, but only with a version number increase in 
> the C-API (we would have to change the c-signature of the ufunc tp_call. 
>
> This would mean that the next release of NumPy would be binary 
> incompatible with packages built to previous NumPy releases.  
>
> I've really been trying to avoid doing that.  So, unless there are 
> strong requests for this feature that outweigh the negatives of 
> re-building dependent packages, then this feature will have to wait. 
>
> OTOH:   I suppose it could be implemented in a different way (using 
> indexing or a method call):
>
> sqrt[complex](a)   --- I remember Tim suggesting some use for indexing 
> on ufuncs earlier though.
>   
It wouldn't surprise me if I did -- it sounds like the kind of thing I'd 
propose -- but I certainly can't remember what I was proposing.

-tim


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