Ticket #2036 (closed defect: fixed)

Opened 7 months ago

Last modified 1 month ago

CPLAtof() - different results than atof()

Reported by: warmerdam Assigned to: mloskot
Priority: high Milestone: 1.5.2
Component: OGR_SRS Version: svn-trunk
Severity: major Keywords: CPLAtof
Cc: dron, mloskot, msieczka, neteler, warmedam

Description

The following precision different between atof() and CPLAtof() is having annoying "knock on" affects on generation of EPSG definition files. 

warmerda@amd64[45]% cat test1.cpp 
#include "gdal.h"
#include "cpl_conv.h"

int main()

{
        double x1, x2;
        const char *str = "6356566.435";

        x1 = atof(str);
        x2 = CPLAtof(str);

        printf( "%.16g, %.16g\n", x1, x2 );
}
warmerda@amd64[46]% ./test1
6356566.435, 6356566.435000001
(gdb) run
Starting program: /wrk/home/warmerda/test1 
[Thread debugging using libthread_db enabled]
[New Thread 46912564802784 (LWP 354)]
[Switching to Thread 46912564802784 (LWP 354)]

Breakpoint 1, main () at test1.cpp:8
8               const char *str = "6356566.435";
(gdb) n
10              x1 = atof(str);
(gdb) 
11              x2 = CPLAtof(str);
(gdb) 
13              printf( "%.16g, %.16g\n", x1, x2 );
(gdb) p x1
$1 = 6356566.4349999996
(gdb) p x2
$2 = 6356566.4350000005

Change History

11/30/07 10:09:30 changed by dron

  • status changed from new to assigned.
  • owner changed from warmerdam to dron.

I have reproduced this problem and also constructed few more cases when CPLAtof() results differs from the libc's atof(): some of my tests started to fail when I reduced the tolerance threshold to 0.0000000000000001. It seems that CPLAtof() typically overestimates the value, but the standard atof() underestimates it.

I will take a look what can be done about that (though, the whole floating point topic is a delicate matter).

By the way, maybe we should not use two different atof() implementations in the same software? It is pretty easy to add the locale aware variant of the CPLAtof() and stop using the standard atof() completely. Otherwise it is possible that we will constantly come to issues like that in the future.

Best regards, Andrey

12/04/07 12:10:49 changed by mloskot

  • cc changed from dron to dron, mloskot.

04/23/08 15:09:22 changed by msieczka

  • priority changed from normal to high.
  • cc changed from dron, mloskot to dron, mloskot, msieczka.

This also affect PROJ 4.6.0.

Compare the PROJ.4's epsg file in version 4.5.0 and 4.6.0, and see how parameters differ in many SRS definitions, eg. EPSG 26794-26798, 2180, 2255-2262, 2057, 2000-2007 and more. Eg.: 

4.5.0:
<4009> +proj=longlat +a=6378450.047548896 +b=6356826.621488444 +no_defs <>

4.6.0:
<4009> +proj=longlat +a=6378450.047548897 +b=6356826.621488445 +no_defs  <>

4.5.0:
<2965> +proj=tmerc +lat_0=37.5 +lon_0=-85.66666666666667 +k=0.999967 +x_0=99999.99989839978 +y_0=249999.9998983998 +ellps=GRS80 +datum=NAD83 +to_meter=0.3048006096012192 +no_defs  <>

4.6.0:
<2965> +proj=tmerc +lat_0=37.5 +lon_0=-85.66666666666667 +k=0.999966667 +x_0=99999.99989839978 +y_0=249999.9998983998 +ellps=GRS80 +datum=NAD83 +to_meter=0.3048006096012192 +no_defs  <>

4.5.0:
<2180> +proj=tmerc +lat_0=0 +lon_0=19 +k=0.999300 +x_0=500000 +y_0=-5300000 +ellps=GRS80 +units=m +no_defs  <>

4.6.0:
<2180> +proj=tmerc +lat_0=0 +lon_0=19 +k=0.9993000000000001 +x_0=500000 +y_0=-5300000 +ellps=GRS80 +units=m +no_defs  <>

04/24/08 04:17:09 changed by neteler

  • cc changed from dron, mloskot, msieczka to dron, mloskot, msieczka, neteler.

04/24/08 07:07:13 changed by dron

The problem is in the way how _Ldmul() function works. To fix it that function (or, more generally, _Ldtento()) should be reimplemented. I will think what can I do about that.

05/06/08 09:09:16 changed by dron

  • status changed from assigned to closed.
  • resolution set to fixed.

This is should be fixed now with the r14379.

05/10/08 08:12:03 changed by msieczka

  • status changed from closed to reopened.
  • resolution deleted.
  • severity changed from normal to major.

Please backport this fix to stable branch, as it's Milestone is 1.5.2.

05/10/08 10:28:34 changed by mloskot

  • status changed from reopened to new.
  • owner changed from dron to mloskot.

I'm taking the porting task on myself

05/10/08 10:33:39 changed by rouault

  • cc changed from dron, mloskot, msieczka, neteler to dron, mloskot, msieczka, neteler, warmedam.

Mateusz,

I'd suggest you to wait a bit about #2036 as there's a pending issue with the fact that CPLStrtof and CPLStrtofDelim have been removed. See http://lists.osgeo.org/pipermail/gdal-dev/2008-May/017031.html

05/10/08 10:37:32 changed by mloskot

Even,

You are right. I'll wait until this issue is clarified.

05/14/08 13:22:53 changed by dron

Folks, I have restored these two functions back. See r14464.

05/29/08 11:33:56 changed by msieczka

Hi Mateusz

Do you think it would be now possible for you to backport the fix into the stable branch?

Cheers, Maciek

05/29/08 13:10:20 changed by mloskot

  • status changed from new to assigned.
  • owner changed from mloskot to mloskot.

05/29/08 13:10:46 changed by mloskot

  • status changed from assigned to closed.
  • resolution set to fixed.

Ported recent fixes to branches/1.5 (r14568). Closing.