I have written a Go implementation of the Grisu 1 algorithm
from Florian Loitsch's paper:
http://florian.loitsch.com/publications/dtoa-pldi2010.pdf
The double-conversion library hosted at
http://code.google.com/p/double-conversion/
uses the Grisu3 algorithm which aims at finding the shortest
approximation in addition to the mere conversion.
The Grisu1 algorithm implements a suboptimal printing that
somewhat guarantees that re-reading the output string will
give back the original float64. Its advantage is that it has
constant complexity w.r.t the exponent.
The Grisu2 and 3 variations can provide %g like features.
Here are some benchmarks:
strconv_test.BenchmarkAppendGrisu1Decimal 582 ns/op
strconv_test.BenchmarkAppendGrisu1 605 ns/op
strconv_test.BenchmarkAppendGrisu1Exp 581 ns/op
strconv_test.BenchmarkAppendGrisu1NegExp 618 ns/op
strconv_test.BenchmarkAppendGrisu1Big 611 ns/op
strconv_test.BenchmarkAppendFloatDecimal 600 ns/op
strconv_test.BenchmarkAppendFloat 3029 ns/op
strconv_test.BenchmarkAppendFloatExp 10591 ns/op
strconv_test.BenchmarkAppendFloatNegExp 42134 ns/op
strconv_test.BenchmarkAppendFloatBig 2803 ns/op
Notes:
* AppendFloatNegExp is a test I have added where the
input value is -5.11e-95.
* The benchmarks are unfair because the AppendFloat benchmark
also looks for the shortest faithful representation.
* The AppendFloat benchmark is done with CL 5491064 and 5494060
applied.
* The benchmarks are done on amd64 platform.
Would it be possible that a Grisu-based algorithm is accepted
in the strconv package for cases if it can provide the same
functionality?
Regards,
--
R�my.