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

[Gerald I. Evenden]

On Thursday 09 November 2006 1:40 am, Glynn Clements wrote:
> cp wrote:
> > The numbers have effectively right and exact representations in ten-bytes
> > format, but the compiler instead of making r/60 makes r * 1/60 so it
> > changes a little thing. I precise that this is done without any
> > optimization (force no optimization) and with option "don't correct FDIV
> > flaw" (for old processors) and "no quick floating points".
>
> In that case, the Borland compiler is entirely useless for any code
> which makes non-trivial use of floating-point arithmetic.
>
> Even if this particular issue can be worked around, you are likely to
> encounter similar issues time and time again.
>
> Any compiler written by someone who doesn't understand that x/y and
> x*(1/y) aren't equivalent simply isn't worth the disk space it
> occupies.

That argument does not hold too well.  I altered the origin problem as 
follows;

#include <math.h>
#include <stdio.h>
static int res1,res2;
int main()
{
        double r=240.0;
//      double tmp = 1./60.;
        double tmp = 0.016666666666666666666666666666666666666;
//      res1 = r / 60.;
        res1 = r * tmp;
        res2 = floor(r / 60.);
        printf("%s\n",(res1==res2) ? "OK!" : "NOT OK!");
        printf("res1: %d   res2: %d\n", res1, res2);
//      getch();
}

Both cases (1/60., 0.01666--) run as:

./a.out
OK!
res1: 4   res2: 4

using a temporary value for "1/60." a la Borland and in both cases the 
procedure ran "OK."

I am still suspicious of the setting of the FPU's rounding flag.

This does raise in my mind: what should the default state of the rounding flag 
be?

-- 
The whole religious complexion of the modern world is due
to the absence from Jerusalem of a lunatic asylum.
-- Havelock Ellis (1859-1939)  British psychologist