printf() metaprogramming challenge

[Walter Bright]

On 5/25/2019 1:42 AM, Joseph Rushton Wakeling wrote:
> FWIW the Ryu algorithm looks like a serious piece of work — see this paper, 
> which references (and compares in detail) to the paper you linked to:
> https://dl.acm.org/citation.cfm?id=3192369
> 
> It covers in some detail the rationale for the differences you note.

Thank you. I've saved a copy of the paper. It it is indeed

1. faster
2. more accurate
3. supports all the options (precision, etc.) with %e %f %g

then it is indeed a candidate for inclusion in Phobos' std.format. But not for 
this exercise.

>> Floating point formatting is not something that can be knocked out in an hour. 
>> You can get a "mostly working" implementation that way, but not a serious, 
>> robust, correct implementation with the expected flexibility. (And the test 
>> cases to prove it correct.)
> 
> One interesting remark in the paper on the Ryu algorithm: "We did not compare 
> our implementation against the C standard library function printf, as its 
> specification does not include the correctness criteria set forth by Steele and 
> White [15], and, accordingly, neither the glibc nor the MacOS implementation does."

The C standard library does indeed not have correctness criteria for floating 
point formatting nor for the trig functions, and that does lead to some sloppy 
implementations, but the mainstream compilers do it well and are expected to.

I once attended a presentation on numerics by a math professor, who said the C 
trig functions on FreeBSD were extremely reliable. He was rather upset (and 
didn't believe me) when I said I'd tested them and found errors in the last digit.

It should be a point of pride for the D language to have the floating point 
"good to the last bit" and I'm always interested in contributions that get us there.