Re: 11706 vs ([lno] Canonical iv creation)

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

Paolo Carlini <pcarlini@suse.de> writes:

| Gabriel Dos Reis wrote:
| 
| >The point I'm trying to make is that built-ins that raise to integer
| >exponent are something that have already been discussed with Roger (I
| >think he implemented, but that ought to be double-checked) and that
| >the is right place to deal with that.  Normally, we should have
| >
| >    double pow(double x, int n) { return __builtin_powi(x, n); }
| >                                                      ^
| >and so on. Note the use use of the built-ins that raises to integer pow.
| >
| I see, the cleanest solution,

It would be misleading to let people believe that is only about
"cleaness".  The raison d'être of pow(T, int) is precesily that common
implementations of pow(T, floating-point) try to recover an
information they don't have access to but which where available at the
call site, namely whether the exponent is integer or not and apply the
appropriate algorithm.  The pow() we are discussing was provided as a
way to communicate that information to the library.  
Forwarding the call back again to pow(T, floating-point) defeats the
whole purpose of pow(T, int).  It is pessimization -- note calls to
pow() are not just with constant integers.  I don't see that
as improvement.

| but they are not yet available (just checked)
| 
| Therefore, is there something we can do for 3.4? Would you object to me
| specializing __cmath_power for 3.4?

yes, because I dont see it a gain given the above.
For 3.5.x, we should implement the agreement we had last summer.

-- Gaby