Stefan van der Walt wrote:
On Wed, Apr 12, 2006 at 01:14:54AM -0500, Robert Kern wrote:
Stefan van der Walt wrote:
Why is the square root of -1 not equal to the square root of -1+0j?
In [5]: N.sqrt(-1.) Out[5]: nan
In [6]: N.sqrt(-1.+0j) Out[6]: 1j
It is frequently the case that the argument being passed to sqrt() is expected to be non-negative and all of their code strictly deals with numbers in the real domain. If the argument happens to be negative, then it is a sign of a bug earlier in the code or a floating point instability. Returning nan gives the programmer the opportunity for sqrt() to complain loudly and expose bugs instead of silently upcasting to a complex type. Programmers who *do* want to work in the complex domain can easily perform the cast explicitly.
The current docstring (specified in generate_umath.py) states
y = sqrt(x) square-root elementwise.
It would help a lot if it could explain the above constraint, e.g.
y = sqrt(x) square-root elementwise. If x is real (and not complex), the domain is restricted to x>0.
I'll get around to it sometime. In the meantime, please make a ticket: http://projects.scipy.org/scipy/numpy/newticket
In [9]: N.divide(1.,0) Out[9]: inf
x/y ?
On my system, x/y (for x=0., y=1) throws a ZeroDivisionError. Are the two divisions supposed to behave the same?
Not exactly, no. Specifically, the error handling is, by design, more flexible with numpy than regular float objects. If you want that flexibility, then you need to use numpy scalars or ufuncs. -- Robert Kern robert.kern@gmail.com "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco