pow( -INFINITY, 0.5 )

[Tim Peters]

If it bothers you that

   current_pow(-inf,0.5) = +inf silently

is not the same as

   ieee_sqrt(-inf) = qNaN and signal invalid

it should also bother you that

   current_pow(-0,0.5) = +0 silently

is not the same as

   ieee_sqrt(-0) = -0 silently


current_pow satisfies the pleasing

   pow(1/x,0.5) is identical (both result & exceptions) to 1/pow(x,0.5)

when x is an infinity or zero, while ieee_sqrt(1/x) and 1/ieee_sqrt(x)
are not always the same (they differ for x in {-inf, -0}).

The special cases here are really an interlocking rat's nest, and
consistent changes are hard won.  E.g., you want also to preserve that
pow(x,y) = pow(1/x,-y) when possible.  So if you change pow(-inf,0.5) to
be NaN instead of the current +inf, you should also change
pow(1/-inf,-0.5) = (one hopes!) pow(-0,-0.5) to be NaN instead of the
current +inf.  But then pow(-0,-0.5) "should be" the same as
1/pow(-0,0.5) too, and for the latter to be a NaN you need to define
pow(-0,0.5) to be a NaN.  Nobody would be happy with pow(-0,0.5) = NaN.


The point is that it's not possible to meet both of the following
simultaneously:

1) pow endcases satisfy the basic identities relating reciprocals and
   exponent negation

2) pow(x,0.5) handles endcases the same as ieee_sqrt(x)

The hangup is not in the defn of pow, but that IEEE's sqrt endcases
don't always meet sqrt(1/x) = 1/sqrt(x).

and-if-i-ever-see-an-actual-program-that-relies-on-sqrt-of-minus-zero-
   being-minus-zero-i'll-probably-die-laughing<grin>-ly y'rs  - tim

Tim Peters   timaksr.com
not speaking for Kendall Square Research Corp