RE: [gfortran] Compute x**(-n) as (1/x)**n

["Djip" <jean-philippe dot perois at wanadoo dot fr>]

> Paul Brook already gave you the party line, for which I'll quote chapter
> and verse here (from the upcoming Fortran 2003 Standard):

OK I didn't notice that (x)**(-n) was a Function => you can compute it like
1/(x**n) or (1/x)**n
So ok for Fortran standard! SORRY!

> However, there's a more fundamental problem with your example.  As I
> explained to Tobias Schlueter, INTEGERs have been dealt with before
> control reaches my change.

- My sample work with all x where x can be representable in IEEE754 format 
And 1/x can't (10,5 is in this case too).... 
 
> So the only way you could have an integer in that part of the code is
> the hugely improbable case of finding an integer, representable in the
> particular floating point format among the "regular" numbers.
> 
> As an exercise to the reader, compute the chance that you will find an
> exactly representable integer in a stream of floats that follows the
> standard IEEE 754 double format (i.e., 53 bits of mantissa, with the
> hidden bit, and 11 bits of (biased) exponent), when the floats are drawn
> from an uniformly distributed sample of representable floating point
> numbers.
 
 So the exercise is more to find the chance to pick in the stream a IEEE754
double format where 1/x have not an exact IEEE 754 double format

(Idee: I think only 2**(z) z?[-(2*11),(2*11] have 1/x IEEE754 format 
       => (2^53) chance(?) to be in my case!

> Henceforth, explain to me why I should forego an optimization to cater
> for this exceptional case (where I basically drag the exceptional case
> down to the same precision as the general one).

Just because (if not an exception) most Fortran user are scientific with
iterative algorithms that hate bad result because of approximation more than
longer execution. 

But like Paul point you are Fortran standard => don't worry with that!

Henceforth, After looking in my sample (Night is good!)... I think I made
mistake in computing the error... not sure on the correct... expect both on
the same order!

> --
> Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
> Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
> Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
> A maintainer of GNU Fortran 95: http://gcc.gnu.org/fortran/
> 
> PS: Resistance is futile, you will be approximated.

PS: On difficult convergence lot of approximation can generate instability.