Re: [RFC] What to do for complex::pow(0, 0)

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

Paolo Carlini <pcarlini@suse.de> writes:

| Hi,
| 
| as you all know well, I mean to improve a bit the consistency of our
| implementation in this special case, strictly speaking not regulated
| by the C++ standard, I briefly remind you.
| 
| In my opinion, it's the right time, because finally Roger's work on
| __builtin_signbit is in, thus all the options are viable. Also, we
| have got a new PR and the use that we are already making of
| __builtin_cpow makes the consistency issue more pressing.
| 
| In short, I see two possible options, here:
| 
| 1- Leave everything mostly as-is, besides a tweak to
| __complex_pow(const complex<>&, const complex<>&), removing the check
| for __x == T(). This means that we are going to return, rather
| consistently and reliably, (nan, nan). I say -rather- because, in case
| the underlying cpow exploited by __builtin_cpow actually returns (1,
| 0) we are in "trouble". AFAIK, this is rather uncommon, but happens
| for an HP libc, for instance.
| 
| 2- Tweak complex::pow to return consistently (1, 0). This means
| exploting the new __builtin_signbit in pow(const complex<>&, const T&)
| and adding/tweaking a few conditionals to handle this special case (*)
| 
| As you probably know well by now ;), I prefer option 2, seems more
| consistent with C99 on real pow, etc., but it's slightly more tricky
| to implement, still absolutely doable (I should check, however, that
| __builtin_signbit works well also for IBM 128-bit long double format,
| I'm asking Roger, to be sure)


I strongly believe -2- is the wrong thing to do.

-- Gaby