[Proj] bugfix PROJ.4 release?

[Gerald I. Evenden]

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