<HTML dir=ltr><HEAD><TITLE>Re: [Proj] bugfix PROJ.4 release?</TITLE>
<META http-equiv=Content-Type content="text/html; charset=unicode">
<META content="MSHTML 6.00.6000.16674" name=GENERATOR></HEAD>
<BODY>
<DIV id=idOWAReplyText90748 dir=ltr>
<DIV dir=ltr><FONT face="Times New Roman" color=#000000 size=2>In regards to "reality checks," the specification written by the United States National Geodetic Survey for map projection transformations is for the maintenance of computational accuracy of plus or minus one-tenth of a millimeter between forward and invese solutions. Anything "better" than that is silliness and not part of the national specification for the North American Datum of 1983. (Special Publication Number 5 by James Stem (in pdf format) available from <A href="http://www.ngs.noaa.gov">www.ngs.noaa.gov</A> .)</FONT></DIV>
<DIV dir=ltr><FONT size=2></FONT> </DIV>
<DIV dir=ltr><FONT size=2>I have had to correct junior engineers in the past regarding changing Fortran format statements ... increasing the number of decimal points displayed does NOT increase the accuracy of the input data! In like fashion, double-double/quad precision/long double accomplishes nothing but expend extra electrons in this <U>particular </U>context. A googolplex of these computations might save a barrel of oil ... ! :-)</FONT></DIV>
<DIV dir=ltr><FONT size=2></FONT> </DIV>
<DIV dir=ltr><FONT size=2>Ahem.</FONT></DIV>
<DIV dir=ltr><FONT size=2></FONT> </DIV>
<DIV dir=ltr><FONT size=2>Cliff Mugnier</FONT></DIV>
<DIV dir=ltr><FONT size=2>LOUISIANA STATE UNIVERSITY</FONT></DIV></DIV>
<DIV dir=ltr><BR>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> proj-bounces@lists.maptools.org on behalf of Gerald I. Evenden<BR><B>Sent:</B> Mon 30-Jun-08 18:32<BR><B>To:</B> PROJ.4 and general Projections Discussions<BR><B>Subject:</B> Re: [Proj] bugfix PROJ.4 release?<BR></FONT><BR></DIV>
<DIV>
<P><FONT size=2>On Monday 30 June 2008 2:53 pm, Maciej Sieczka wrote:<BR>> Frank,<BR>><BR>> Now that the "CPLAtof() - different results than atof()" [1] bug in GDAL<BR>> is fixed, do you think you could regenerate the broken PROJ.4's epsg<BR>> file and provide a bugfix PROJ.4 release?<BR>><BR>> [1]<A href="http://trac.osgeo.org/gdal/ticket/2036">http://trac.osgeo.org/gdal/ticket/2036</A><BR>><BR>> Best,<BR>> Maciek<BR><BR>This is a simple little program I wrote because of the contents of the above<BR>web site:<BR>#include <stdio.h><BR>#include <float.h><BR> int<BR>main(char **argc, int narg) {<BR> printf("FLT_DIG: %d\n",FLT_DIG);<BR> printf("DBL_DIG: %d\n",DBL_DIG);<BR> printf("LDBL_DIG: %d\n",LDBL_DIG);<BR>}<BR>Executing it yields the following results:<BR>FLT_DIG: 6<BR>DBL_DIG: 15<BR>LDBL_DIG: 18<BR><BR>In case you have not guessed, these are the significant decimal digits on my<BR>machine---a 64 Inte---for type float, double and long double. All work work<BR>that I do does not extend beyond DBL or "double x" and I suspect that the<BR>software producing the results on the web site has about the same<BR>characteristics.<BR><BR>MY burning, yes *very* burning, question is what are data numbers containing<BR>16 digits doing on the display??? And why, why would anyone ever worry that<BR>they do not match to 16 digits???!!!!<BR><BR>Secondly, and probably more importantly, Earth parameters are probably not<BR>more significant than 10 digits (milimeters for radius). And that is<BR>probably *very* optimistic.<BR><BR>And someone is worried that two procedures that cannot agree to 16 digits??<BR><BR>How about a little reality check folks.<BR><BR>If you want to reduce the "annoying effect" try reducing the format to<BR>say %.4g---and that is overkill.<BR>--<BR>The whole religious complexion of the modern world is due<BR>to the absence from Jerusalem of a lunatic asylum.<BR>-- Havelock Ellis (1859-1939) British psychologist<BR>_______________________________________________<BR>Proj mailing list<BR>Proj@lists.maptools.org<BR><A href="http://lists.maptools.org/mailman/listinfo/proj">http://lists.maptools.org/mailman/listinfo/proj</A><BR></FONT></P></DIV></BODY></HTML>