Re: Ryu floating point output patch - Mailing list pgsql-hackers

From Donald Dong
Subject Re: Ryu floating point output patch
Date
Msg-id 33F72D1B-40E0-428D-893C-D2D34B12C8D8@csumb.edu
Whole thread Raw
In response to Re: Ryu floating point output patch  (Andres Freund <andres@anarazel.de>)
Responses Re: Ryu floating point output patch  ("David G. Johnston" <david.g.johnston@gmail.com>)
List pgsql-hackers
> On Jan 11, 2019, at 10:40 AM, Andres Freund <andres@anarazel.de> wrote:
>
> And of course it'd change the dump's text contents between ryu and
> non-ryu backends even with extra_float_digits = 3, but the resulting
> floats ought to be the same. It's just that ryu is better at figuring
> out what the minimal text representation is than the current code.

+1. I spent some time reading the Ryu paper, and I'm convinced.

I think Ryu will be a good choice we want to have as many digits as possible
(and roundtrip-safe). Since we have the extra_float_digits and ndig, the Ryu may
give us more digits than we asked.

Maybe one way to respect ndig is to clear the last few digits of (a, b, c)
(This is the notation in the paper. I think the code used different var names)
in base 10,
https://github.com/ulfjack/ryu/blob/b2ae7a712937711375a79f894106a0c6d92b035f/ryu/d2s.c#L264-L266
  // Step 3: Convert to a decimal power base using 128-bit arithmetic.
  uint64_t vr, vp, vm;
  int32_t e10;
for Ryu to generate the desired string?

Also I wonder why do we need to make this change?
-int                    extra_float_digits = 0; /* Added to DBL_DIG or FLT_DIG */
+int                    extra_float_digits = 1; /* Added to DBL_DIG or FLT_DIG */

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Shared buffer access rule violations?
Next
From: Chapman Flack
Date:
Subject: Re: PostgreSQL vs SQL/XML Standards