ryu VS itoa

Nah. This is about ryu printf.

> Google put in significant engineering effort into "Ryu", a parsing library for double-precision floating point numbers: https://github.com/ulfjack/ryu

It's not a parsing library, but a printing one, i.e., double -> string. https://github.com/fastfloat/fast_float is a parsing library, i.e., string -> double, not by Google though, but was indeed motivated by parsing JSON fast https://lemire.me/blog/2020/03/10/fast-float-parsing-in-prac...

Me and Ryu agree that the answer should be 0.30000000000000004

Apparently exact minimal float-to-string conversion is more recent than I thought, and many languages used to print more (Python?) or less (PHP) decimal digits than necessary to uniquely identify the bit pattern. Python correctly prints 46000.80 + 553.04 as 46553.840000000004, but I don't know if it ever prints more digits than needed. One recent algorithm for printing floats exactly is https://github.com/ulfjack/ryu, though I'm unaware what's the state-of-the-art (https://github.com/jk-jeon/dragonbox claims to be a benchmark and the best algorithm).

On the huge speedup side, you have the Ryū algorithm for decimal conversion (Video, Source), which is now finding its way in most standard libraries. But it isn't a hack, and a very dense, complex and precise algo, nothing like the fast-and-loose inverse square root.

Used a wizard's magic to print "3.14" faster

Here's a paper that details an optimized algorithm (reference implementation). It also contains a description of a correct, but slow algorithm as well as references to classic papers on the subject. Earlier the classic implementation was the dtoa one included in netlib by David Gay.

At the very core of all these theoretical stuffs, there is the theory of continued fractions. This is an immensely useful monster which I even dare call as the ultimate tool for floating-point formatting/parsing that everyone who wants to contribute in this field should learn. Before I learned continued fractions, my main tool for proving stuffs was the minmax Euclid algorithm (which is one of the greatest contributions of the wonderful Ryu paper), but it turns out that it is actually just a quite straightforward application of the theory of continued fractions. The main role minmax Euclid algorithm played was to estimate the maximum size of possible errors, but with continued fractions it is even possible to find the list of all examples that generate errors above a given threshold. This is something I desperately wanted but really couldn't do back in 2020.

Ryū algorithm, the converse (doubles to strings), is also much faster than using Java's number formatting classes.

https://github.com/ulfjack/ryu/blob/master/src/main/java/inf...

I know, I was just being lazy 😏. This is also why itoa_always_10_digits performs the best in the benchmark, while it is in fact horribly slow for realistic data. If you care, here is a benchmark with a more realistic data: https://github.com/jeaiii/itoa.

Faster digit generation, based on a jeaiii-style digit generation routine.