On 2018-09-26 21:44:41 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > Reading around the interwebz lead me to look at ryu
>
> > https://dl.acm.org/citation.cfm?id=3192369
> > https://github.com/ulfjack/ryu/tree/46f4c5572121a6f1428749fe3e24132c3626c946
>
> > That's an algorithm that always generates the minimally sized
> > roundtrip-safe string output for a floating point number. That makes it
> > insuitable for the innards of printf, but it very well could be
> > interesting for e.g. float8out, especially when we currently specify a
> > "too high" precision to guarantee round-trip safeity.
>
> Yeah, the whole business of round-trip safety is a bit worrisome.
Seems like using a better algorithm also has the potential to make the
output a bit smaller / more readable than what we currently produce.
> If we change printf, and it produces different low-order digits
> than before, will floats still round-trip correctly? I think we
> have to ensure that they do.
Yea, I think that's an absolutely hard requirement. It'd possibly be a
good idea to add an assert that enforce that, although I'm not sure
it's worth the portability issues around crappy system libcs that do
randomly different things.
> BTW, were you thinking of plugging in strfromd() inside snprintf.c,
> or just invoking it directly from float[48]out? The latter would
> presumably be cheaper, and it'd solve the most pressing performance
> problem, if not every problem.
I wasn't actually seriously suggesting we should use strfromd, but I
guess one way to deal with this would be to add a wrapper routine that
could directly be called from float[48]out *and* from fmtfloat(). Wonder
if it'd be worthwhile to *not* pass that wrapper a format string, but
instead pass the sprecision as an explicit argument. Would make the use
in snprintf.c a bit more annoying (due to fFeEgG support), but probably
considerably simpler and faster if we ever reimplement that ourself.
Greetings,
Andres Freund