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

From Andres Freund
Subject Re: Ryu floating point output patch
Date
Msg-id 20190111200311.upz372wgnfuvvxoq@alap3.anarazel.de
Whole thread Raw
In response to Re: Ryu floating point output patch  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Ryu floating point output patch  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
List pgsql-hackers
Hi,

On 2019-01-11 14:54:55 -0500, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > 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.
> 
> I'm fairly concerned about this blithe assertion that the ryu code is
> smarter than the rest of the world.

The paper on which ryu is based seems to have quite some careful
analysis behind it, explaining why it's correct (i.e. why the algorithm
generates the minimal output, but not output that's imprecise). Although
I certainly didn't invest substantial amounts of time reviewing the
correctness of the logic therein, and would quite possibly fail due to
insufficient maths chops if I tried.


> In particular, how does it know how every strtod() on the planet will
> react to specific input?

strtod()'s job ought to computationally be significantly easier than the
other way round, no? And if there's buggy strtod() implementations out
there, why would they be guaranteed to do the correct thing with our
current output, but not with ryu's?

Greetings,

Andres Freund


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Ryu floating point output patch
Next
From: Tomas Vondra
Date:
Subject: Re: Checksum errors in pg_stat_database