Re: Ryu floating point output patch

> 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 */