>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:
Tom> However, it seems like it should still be on the table to look at
Tom> other code that just does sprintf's job faster (such as the stb
Tom> code Alexander mentioned).
The stb sprintf is indeed a lot faster for floats than other sprintfs,
but (a) it's still quite a lot slower than Ryu (COPY of my test table is
4.2 seconds with stb, vs 2.7 seconds with Ryu), and (b) it also produces
changes in the insignificant digits, so while (it claims) the values are
still round-trip convertible, they are neither the shortest
representation nor the exact representation.
For example, consider 1.9, which is 0x3FFE666666666666:
exact value: 1.899999999999999911182158029987476766109466552734375
accepted input range:
min: 1.89999999999999980015985556747182272374629974365234375
max: 1.90000000000000002220446049250313080847263336181640625
exact value rounded to 18 SF: 1.89999999999999991
Ryu output: 1.9E0
STB (%*.18g) output: 1.89999999999999992
sprintf (%*.18g) output: 1.89999999999999991
So while STB's output is in the acceptable range, it's not the result of
rounding the exact value to 18 digits (as sprintf does on my system at
least) and nor is it the shortest. Testing a bunch of random values it
usually seems to be off from the rounded exact result by +/- 1 in the
last digit.
--
Andrew (irc:RhodiumToad)
