Re: __builtin_cpow((0,0),(0,0))

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

Vincent Lefevre <vincent+gcc@vinc17.org> writes:

| On 2005-03-09 12:45:57 +0100, Duncan Sands wrote:
| > The problem is x^0.0 (real exponent), not x^0 (integer exponent).
| 
| Well, mathematically, you can distinguish these two functions:
| 
|   powrr: RxR -> R (not defined on (0,0) in particular)
| 
| and
| 
|   powrz: RxZ -> R (where powint(0,0) = 1)
| 
| and even other two functions, where R is replaced by C (the complex
| numbers). Unfortunately, the C language doesn't distinguish them.

That is no reason for the compiler not to distinguish them.  There are
plenty of stuff the C language does not distinguish but the compiler
has to.

Notice that LIA-2 says in its rationale (§B.5.3.6)

  [...] There is a problem for power_F(x,y) if both x and y are zero: 
  -- Ada raises an `exception' for the operation that is close in
  semantics to power_F when both arguments are zero, in accordance
  with the fact 0^0 is mathematically undefined.
  
  -- The X/OPEN Portability Guide, as well as C9x, specifies for
     pow(0,0 a return value of 1, and no notification.  This
     specification agrees with the recommendations in [51, 53, 54, 57].

  The specification in LIA-2 follows Ada, and returns invalid for
  power_F(0,0), because of the risks inherent in returning a result
  which might be inappropriate for the application at hand.  Note
  however, that power_FI(0,0) is 1, without any notification.  The
  reason is that the limiting value for the corresponding mathematical
  function, when following either of the only two continuous paths, is
  1.  This also agrees with the Ada specification for a floating point
  value raised to the power in an integer datatype, as well as that
  for other programming languages which distinguish there operations.

  Along any path defined by y = k/ln(x) the mathematical function x^y
  has the value exp(k).  It follows that some of the limiting values
  for x^y depend on the choice of k, and hence are undefined, as
  indicated in the specification.

| > Now in practice I can imagine that a language confuses x^integer and
| > x^real by mapping them to the same function, or only provides a
| > function for doing x^real. Perhaps this is the case with C?
| 
| Yes, and to compute complex^integer, you need to use cpow(), AFAIK.

No, you don't need cpow().

| I think this is the reason why cpow((0,0),(0,0)) should return 1,
| just like pow(0,0).

That is a bogus reason.

-- Gaby