[postgis-devel] Inconsistencies in text output

[Martin Davis]

Turns out that you can roundtrip IEEE754 -> text -> IEEE754.  It requires
17 significant dights.

https://stackoverflow.com/questions/2480790/exact-textual-representation-of-an-ieee-double

That's assuming that the C FP output works in the correct way. If not, I
guess we could implement that Burger's algorithm mentioned - which is what
Python does, apparently.  Although is it really worth the complexity?

On Fri, Apr 17, 2020 at 9:53 AM Martin Davis <mtnclimb at gmail.com> wrote:

>
>
> On Fri, Apr 17, 2020 at 9:35 AM <rmrodriguez at carto.com> wrote:
>
>>
>> I wanted a way to ensure there would be no loss of information when
>> doing storage1 > wkt/geojson -> storage2 as not having this has caused
>> issues where the stored geometry was valid, but after moving it using
>> GeoJSON it wasn't valid anymore.
>> The solution option there was to ask for more resolution, but since
>> the function isn't working as announced I wouldn't get it.  Yes,
>> ideally the end system should be able to read WKB, but that's not
>> always the case.
>>
>
> So if you specify say 20 decimal digits, you aren't getting them?  It
> seems like this at least should be made to work.  It doesn't sound like a
> bad thing, as long as it doesn't cause *unspecified* precision output to
> get a lot longer.
>
> I'm wondering whether it is actually possible to have no-loss
> round-tripping with binary -> text -> binary?  And if so, how many digits
> are required to guarantee this?
>
> I know it's not possible to round-trip text -> binary -> text, since there
> are decimal numbers which aren't finitely representable in binary (e.g
> 1.3).
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20200417/63c7c681/attachment-0001.html>