On 2018-09-26 21:44:41 -0400, Tom Lane wrote: > Andres Freund <and...@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
