[postgis-devel] Inconsistencies in text output

rmrodriguez at carto.com rmrodriguez at carto.com
Mon Apr 20 12:58:31 PDT 2020


Going to the 0.3 example. exactly as a 64bit double because it is
impossible, so you didn't have it in the first place.

Ryu works over IEEE 754 floating point numbers, so neither of those will
work. Going back to the same example as the other day:

*2.99999999999999988897769753748E-1* could be represented as 29999.../
10000... but ryu will always output "0.3" because that's the sortest
representation for that double value.

Maybe I'm not undertanding you correctly but no system (ryu or otherwise)
can give you any precision that you don't already have. What this does do,
is guarantee (as long as you don't force dropping digits via precision)
that you get the same ieee754 64bit number that you had, exactly as WKB
does.

Related to this, one bad thing about the current (3.0) approach is that is
only uses scientific notation for big numbers, so something like
12345678e-8 is output as 0.000000012345678 which is longer and the default
precision might drop significant digits pretty frequently. I plan to do
some tests and suggest using scientic notation when that is clearly shorter
(both really small and big numbers).


On Monday, April 20, 2020, Martin Davis <mtnclimb at gmail.com> wrote:

>
> It does seem like binary fractions can be represented exactly as decimal
> numbers.  The converse is not true, however.  So does that mean that even
> if a binary FP number is output "exactly" as decimal, it might not read
> back in the same way?  Does ryu support this?  (And even if Ryu does, other
> systems might not).
>
> This in indeed the rationale for WKB - it removes all these kinds of
> finicky questions about round-tripping.
>
> For the record, I'm not concerned about round-tripping, just about
> getting the behavior of limited-precision output correct.
>
> On Mon, Apr 20, 2020 at 9:18 AM <rmrodriguez at carto.com> wrote:
>
>> On Mon, Apr 20, 2020 at 6:10 PM Sandro Santilli <strk at kbt.io> wrote:
>>
>> > Any decimal representation of a floating point number
>> > will have this problem, as not all numbers that can be
>> > represented by a floating point number can fit on a
>> > screen.
>>
>> It has been demonstrated that you can guarantee round-trip conversion
>> with 17 significant digits. It's true that with decimal notation it
>> will require more characters, but with Postgis constraints this seems
>> to require at most 33 characters, which is way less than what a screen
>> fits.
>>
>> I'd be more than happy to add examples of those big numbers to add
>> them to our unit tests and confirm round trip works for them.
>>
>>
>> --
>> Raúl Marín Rodríguez
>> carto.com
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel at lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/postgis-devel
>
>

-- 
Raúl Marín Rodríguez
carto.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20200420/68581b8b/attachment.html>


More information about the postgis-devel mailing list