double-conversion

To be clear, David Gay's dtoa is not a modern implementation of decimal-to-float conversion. There had been several much simpler and performant alternatives, including: - Google's double-conversion [1], which is best known for introducing the Grisu family of new float-to-decimal algorithms but also has a much less documented float-to-decimal algorithm via successive approximations AFAIK. - The Eisel-Lemire algorithm [2], which is a Grisu3-like algorithm and returns either correct digits or a much rare fallback signal and currently in the standard libraries of Go and Rust. - I believe Microsoft's own C Runtime (msvcrt, later ucrt) also has a completely separate code which algorithm is roughly similar to one of above. These implementations also clearly demonstrate that such conversion only needs a bigint support of the bounded size (~3 KB)

Author of Grisu here. It's really surprising, how long it took to find the most efficient algorithms for double-conversions. In 1980 Coonen already published a good algorithm, but that one was kind-of lost. For a long time Steele & White's algorithm was the state-of-the-art (with some improvements here and there over time). Now, Ryu is by far the fastest algorithm out there, but that took ages... Unfortunately, there doesn't seem to be an easy-to-use, complete library for Ryu yet. The Grisu library (https://github.com/google/double-conversion) is probably still the go-to library if you don't want to implement it again...

I'm the author of Grisu. (http://github.com/google/double-conversion and http://florian.loitsch.com/publications/dtoa-pldi2010.pdf) Grisu is also proven to be always correct. As mentioned in another comment: you have to define "correct". Grisu is always accurate, but may bail out if you need the shortest or closest result. Basically: Grisu will always print a number that reads back to the input. However, it may not be able to print the shortest or closest number (when two decimal outputs have the same shortest length). In that case, it knows this, though, and can tell the user. I would say that the combination of Grisu and Errol is currently the state of the art. Errol is not the fastest, nor is it (afaik) proven to always return the closest result. However, combining Grisu with Errol (as fallback) would probably yield the fastest complet

Author here. Grisu is accurate, but not always optimal. However, it figures out when that happens and lets you bail out to a slower algorithm when that happens. If you want full speed you should use Grisu, and then use Errol as a bailout. A bit more context: there are 3 important properties when printing floating-point numbers. - accurateness: you want the printed number to read back to the same number. - shortness: often you want the shortest decimal representation: "0.3" and not "0.2999999999999999889". The latter is more precise, but reads back to the same number as "0.3". - closeness: given two decimal representations of the same length, you prefer the one that is closer to the actual number. I call the combination of these three properties "optimal". Note that shortness and closeness are not always crucial. For example, a json-encode

Great links, thanks. I sometimes noodle with a faster printf for Java, mostly for giggles. I also found these: Dragon4 and Grisu3: Algoritms to Display Floating Point Numbers https://www.clarusft.com/dragon4-and-grisu3-algorithms-to-di... "Printing Floating-Point Numbers Quickly and Accurately with Integers" by Florian Loitsch http://www.cs.tufts.edu/~nr/cs257/archive/florian-loitsch/pr... And its implementation in C https://github.com/google/double-conversion Here's a Java implementation of Grisu2 algorithm. https://github.com/jnordwick/zerog-grisu