[Numpy-discussion] Re: sqrt and divide

Robert Kern robert.kern at gmail.com
Wed Apr 12 14:08:06 CDT 2006

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:


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

More information about the Numpy-discussion mailing list