[Proj] bugfix PROJ.4 release?
Gerald I. Evenden
geraldi.evenden at gmail.com
Mon Jun 30 19:32:27 EDT 2008
On Monday 30 June 2008 2:53 pm, Maciej Sieczka wrote:
> Frank,
>
> Now that the "CPLAtof() - different results than atof()" [1] bug in GDAL
> is fixed, do you think you could regenerate the broken PROJ.4's epsg
> file and provide a bugfix PROJ.4 release?
>
> [1]http://trac.osgeo.org/gdal/ticket/2036
>
> Best,
> Maciek
This is a simple little program I wrote because of the contents of the above
web site:
#include <stdio.h>
#include <float.h>
int
main(char **argc, int narg) {
printf("FLT_DIG: %d\n",FLT_DIG);
printf("DBL_DIG: %d\n",DBL_DIG);
printf("LDBL_DIG: %d\n",LDBL_DIG);
}
Executing it yields the following results:
FLT_DIG: 6
DBL_DIG: 15
LDBL_DIG: 18
In case you have not guessed, these are the significant decimal digits on my
machine---a 64 Inte---for type float, double and long double. All work work
that I do does not extend beyond DBL or "double x" and I suspect that the
software producing the results on the web site has about the same
characteristics.
MY burning, yes *very* burning, question is what are data numbers containing
16 digits doing on the display??? And why, why would anyone ever worry that
they do not match to 16 digits???!!!!
Secondly, and probably more importantly, Earth parameters are probably not
more significant than 10 digits (milimeters for radius). And that is
probably *very* optimistic.
And someone is worried that two procedures that cannot agree to 16 digits??
How about a little reality check folks.
If you want to reduce the "annoying effect" try reducing the format to
say %.4g---and that is overkill.
--
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
mailing list