[Proj] Re: Proj4 Bug (rtodms)
Gerald I. Evenden
gerald.evenden at verizon.mail
Wed Nov 8 12:46:22 EST 2006
On Wednesday 08 November 2006 4:29 am, cp wrote:
> first, excuse me for my poor english.
I have no trouble understanding you so your English is OK by me.
> "Gerald I. Evenden" <gerald.evenden at verizon.mail> a écrit dans le message
> de news: 200611051448.17043.gerald.evenden at verizon.mail...
> > So far, I have not found any way to reproduce your problem and
> > consequently
> > find no reason to change code. However, I do have a couple of questions:
> this simple program produce a "NOT OK" output :
> #include <math.h>
> #include <stdio.h>
> static int res1,res2;
> int main()
> double r=240.0;
> res1 = r / 60.;
> res2 = floor(r / 60.);
> printf("%s",(res1==res2) ? "OK!" : "NOT OK!");
Minor note: what is the "getch" for?
To replicate your example I copied your code into 'sample.c':
static int res1,res2;
res1 = r / 60.;
res2 = floor(r / 60.);
printf("%s",(res1==res2) ? "OK!" : "NOT OK!");
I then did:
gie at charon:~/tmp$ gcc sample.c -lm
gie at charon:~/tmp$ ./a.out
which gives in an "OK" answer.
As for other details:
gcc (GCC) 4.0.3 (Ubuntu 4.0.3-1ubuntu5)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Libc and libm are standard Gnu libraries.
Dual 64 bit processor chip: intel(R) Pentium(R) 4 CPU 3.00GHz
Check the floating point rounding modes (described in Harbison & Steele, 5th
edition, p.481. On my system, gdb (Gnu debugger) displays "info float" as:
Control Word: 0x037f IM DM ZM OM UM PM
PC: Extended Precision (64-bits)
RC: Round to nearest
which seems most appropriate for most applications. Obviously, I do not have
information on controlling these details on your Borland system.
It would be interesting if others with different systems would run the above
test and let us know their results.
> I think that because floor corrects values that were epsilon under the
> absolute value, if epsilon is smaller than the floating point precision.
> my compiler is Borland C++ compiler and I work on Windows XP, but I don't
> think that C runtime libraries at this point are differents ??? (I believe
> not because of portability with Kylix) ???
> > 1. on what hardware (chip) was this problem created,
> Intel Pentium
> > 2. what compiler/library was employed and
> Borland C (CW3230mt.dll)
> > 3, level of optimization specified.
> > Interestingly, r before being divided by 60 does not have a fractional
> > component (exactly equal to 240.). The implication is that the floating
> > point processor produces a "ragged" result where the mantissa is not
> > rational. That is, something like 3.9999... is produced. The floor
> > operation should still have produced 3 as the unchanged code did with
> > simple
> > conversion to integer with the memory assignment of the division
> > operation.
> > I suspect something is gummed up with the handling of the extra bits that
> > are
> > part of the mantissa in the floating point hardware.
> I don't, but the hardware in the FPU works with 10 bytes instead of 8
> because of precision and exact numbers doesn't exist in FPU
> > Lastly, the problem line has been handle by:
> > deg = (int)(r / 60.);
> the problem cannot be resolved by this
> > for some time in the libproj4 library. The cast was necessary to keep
> > the compiler from complaining during -Wall runs.
> > Lastly, rtodms is deprecated and will be replaced with rad2dms which
> > allows
> > for greater format flexibility and is (unlike rtodms) thread proof.
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
More information about the Proj