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 17:37:59 +0100, Gabriel Dos Reis wrote:
| > Vincent Lefevre <vincent+gcc@vinc17.org> writes:
| > | 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.
| 
| Do you mean that the compiler should detect if the second argument
| comes from an integer type?

No.  I mean when I call powi() either through built-ins or appropriate
overload (several programming languages do so), I expect sane semantics.

| > | Yes, and to compute complex^integer, you need to use cpow(), AFAIK.
| > 
| > No, you don't need cpow().
| 
| From this point of view, the math library is useless as one can
| reimplement it entirely. :)

I don't see how that follows from my statement.

|  
| > | 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.
| 
| No more than any other reason.

The asseryion that 0^0 is mathematically undefined is not a bogus reason.
It is a fact.

-- Gaby