Rendering floating point numbers is hard
serpentine.com
serpentine.com
Hmm. I think maybe a weekend hack is in order. Perhaps dtoa in Python can be replaced in a similar fashion, since Python maintains David Gay's algorithm as an upstream source.
http://hg.python.org/cpython/file/fc831c49216d/Python/dtoa.c
EDIT: Looks like there has already been some gripes about the quality of David Gay's implementation.
What a curious benchmark! It makes you wonder all kinds of things like how many IEEE doubles there are; how you sample from them randomly; what kind of coverage of the reals you get; and how relevant it all is.
(There are some subtleties: a "random 64-bit word interpreted as a double" is clearly not uniformly distributed over the reals; x86/amd64 uses 80-bit doubles for intermediate results, except when it doesn't; there are things like subnormals ("really small numbers"), Not-a-Number, Infinity, -Infinity, -0; but the above should give you the right general idea)
In the same way I'm wondering how meaningful it is to say that an algorithm works for 99.49% of all doubles, sampled uniformly. In other words, how could I use that benchmark to make a judgement about using grisu3?
http://www.colorforth.com/pi.htm
[edited to correct blatant error. Thanks Florin]
Either that or pi is a symbol and we use symbolic algebra. Just convert to the result in floating point at the last minute.
Ironically my calculator quite happily manages rational form including PI as a constant:
http://h41111.www4.hp.com/calculators/uk/en/scientific/smart...