[gdal-dev] GDAL precision for Geometry object

[Dimitrianos Savva]

> On Oct 11, 2015, at 7:27 PM, Hermann Peifer <peifer at gmx.eu> wrote:
> 
> On 2015-10-10 13:45, Dimitrianos Savva wrote:
>> 
>> For example the geometry POINT (4799826.09861662145704
>> 2773995.445373429451138) cannot be represented by two double types. But
>> still the ExportToWKT function produces the correct result with full
>> precision for the values.
> 
> While thinking twice about the issue (I might be wrong, though): Isn't it more of a generic problem that by far most reals (of which there are infinite many) cannot be *exactly* represented by half, single, double, quadruple-precision, or by whatever other floating-point format that could ever be invented in the future? In these cases, the "most accurate representation" must simply be good enough, as one can't do much about it?
> 
> Your sample value above is 4799826.09861662145704 (decimal):
> The most accurate representation as double is: 4.79982609861662145704030990601E6 (decimal), 0x41524F54864FBC17 (hex) and : 01000001 01010010 01001111 01010100 10000110 01001111 10111100 00010111 (binary).

You are right.

> That's just how it is, or is there another problem, of which I wouldn't be aware?
> 

I just wondering if GDAL make use of any kind of custom-user-defined type that provides higher precision from a double. 
My question wasn’t so clear. The problem started comparing GDAL’s and GeoTools’ (Java) WKT representations of the same geometries that has been read from the same Shapefile.
I noticed that GDAL provides higher accuracy than GeoTools. So I asked this question here, wondering whether GDAL is using something else than just doubles in memory. 
But I also concluded that in fact JAVA  and C doubles have the same representation in memory by running some minimal tests. 
However in Java, when converting a double into string, it even with (“.15f”) format, it does not give the same string value as doing so in C.

> I took the "most accurate" values from http://www.binaryconvert.com/result_double.html
> 
> @Even: I also tried to imagine a reasonable real-life coordinate value that would generate scientific notation when printed with "%.15g" or: "%.17g" (as hamish mentioned in this old ticket). Can you point me to one?
> 
> Hermann
> 
> 
 
Regards,
Dimis