[Proj] Re: Re: Re: Proj4 Bug (rtodms)

[cp]

"Glynn Clements" <glynn at gclements.plus.com> a écrit dans le message de news: 
17748.52585.67187.399184 at cerise.gclements.plus.com...
>
>
> FWIW, when I try this with:
>
> gcc (GCC) 3.3.6 (Gentoo 3.3.6, ssp-3.3.6-1.0, pie-8.7.8)
>
> on a Pentium 4, I get "OK" if I compile with optimisation (-O1 or
> higher), and "NOT OK" if I compile either without optimisation, or
> with both optimisation and -ffloat-store. I get the same result
> regardless of whether tmp is initialised with 1./60. or 0.01666...
>
> Also, if I use "long double" throughout (including adding a trailing L
> to the FP literals), I get "OK" regardless of the optimisation
> settings.
>
> None of which is surprising when you consider the value of 1/60 at
> various precisions:
>
> precision bits value
>
> single 32 0.0166666675359010696411133
> double 64 0.0166666666666666664353702
> extended 80 0.0166666666666666666674572
>
> At double precision (64 bits), the rounded value is less than 1/60,
> while at extended precision (80 bits) it's greater than 1/60. The
> result of r*tmp would be similarly be less than or greater than 4.0.
>
> As both the integer cast and floor round positive numbers downwards,
> using double precision would result in a value slightly less than 4.0
> being rounded down to 3, while extended precision would result in a
> value slightly greater than 4.0 being rounded down to 4.

Not exactly !  for the C runtime library, even if the result is less than 
4.0, the floor gives 4.0 if the difference is less than the smaller number 
in the precision, here if the difference is less than the double precision.
(I have look at asm code of floor)

>
> The x86 FPU has 80-bit registers, but "double" values will be reduced
> to 64 bits when stored in memory. Optimisation makes it more likely

they can be stored as long double (=> fst tbyte ptr...), so it's not an 
excuse for borland.

> that intermediate results will be kept in registers (and thus not
> truncated), while -ffloat-store causes all FP values to be stored into
> memory then read from there, forcibly discarding any excess precision
> which the FPU may provide:
>

This has give me an idea : I have tried to see the behaviour forcing fast 
floating point (perhaps the compiler gives a different value 1/60 in a stack 
register). Unfortunately not ! It doesn't use FPU stack register in this 
case, Borland compiler gives the same wrong value.

> `-ffloat-store'
>     Do not store floating point variables in registers, and inhibit
>     other options that might change whether a floating point value is
>     taken from a register or memory.
>
>     This option prevents undesirable excess precision on machines such
>     as the 68000 where the floating registers (of the 68881) keep more
>     precision than a `double' is supposed to have.  Similarly for the
>     x86 architecture.  For most programs, the excess precision does
>     only good, but a few programs rely on the precise definition of
>     IEEE floating point.  Use `-ffloat-store' for such programs, after
>     modifying them to store all pertinent intermediate computations
>     into variables.
>
> Of course, none of this is relevant to computing 240.0/60.0, which
> isn't affected by optimisations[1] or rounding modes.
>
> [1] Except for -funsafe-math-optimizations (also used by -ffast-math),
> which specifically enables this kind of approximation. It is never
> turned on by any -O setting:
>
> `-funsafe-math-optimizations'
>     Allow optimizations for floating-point arithmetic that (a) assume
>     that arguments and results are valid and (b) may violate IEEE or
>     ANSI standards.  When used at link-time, it may include libraries
>     or startup files that change the default FPU control word or other
>     similar optimizations.
>
>     This option should never be turned on by any `-O' option since it
>     can result in incorrect output for programs which depend on an
>     exact implementation of IEEE or ISO rules/specifications for math
>     functions.
>
>     The default is `-fno-unsafe-math-optimizations'.
>
> `-ffast-math'
>     Sets `-fno-math-errno', `-funsafe-math-optimizations',
>     `-fno-trapping-math', `-ffinite-math-only' and
>     `-fno-signaling-nans'.
>
>     This option causes the preprocessor macro `__FAST_MATH__' to be
>     defined.
>
>     This option should never be turned on by any `-O' option since it
>     can result in incorrect output for programs which depend on an
>     exact implementation of IEEE or ISO rules/specifications for math
>     functions.
>
> -- 
> Glynn Clements <glynn at gclements.plus.com>
> _______________________________________________
> Proj mailing list
> Proj at lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/proj
>