Replacement for snprintf

berni44 dlang at
Wed Oct 30 19:11:14 UTC 2019

On Wednesday, 30 October 2019 at 17:41:26 UTC, H. S. Teoh wrote:
> If you haven't already, please read:
> especially the papers linked in the first paragraph.

Thanks for that link. I havn't had a look into the grisu 
algorithms. But I'll definitivly do that.

> Formatting floating-point numbers is not a trivial task. It's 
> easy to write up something that works for common cases, but 
> it's not so easy to get something to gives the best results in 
> *all* cases.

I know, that this is something we all wish. Anyway, my goal is 
set somewhat lower: I'd like to replace the existing call to 
snprintf with something that is programmed in D and which should 
be pure, @safe and ctfeable. And ideally it should not be slower 
then snprintf.

> You probably should use the algorithms referenced above for 
> your implementation,

I read through the paper for the ryu algorithm and rejected it 
(at least for me; if someone else is goint to implement it and 
file a PR that's fine). My reason for rejecting is, that the 
algorithm has not exactly the same goal as printf, which IMHO 
means, that it cannot be used here; and that it needs a 
lookuptable, that is too large (300K for 128bit reals).

I fear a little bit, from what I read in the ryu paper about the 
grisu algorithms, that it has the first of the above mentioned 
problems too. But yet I can't tell for sure.

> instead of coming up with your own that may have
> unexpected corner cases that don't produce the right output.

Obviously I need to prove, that the algorithm is correct somehow. 
While this can be done for floats by running it on all numbers 
and comparing these results with the result of snprintf (or the 
result calculated by bc), for doubles and reals, this isn't 
possible anymore (a random sample can be tested anyway, but 
that's no proof). Anyway, I think, that the proof isn't hard to 
give. The current algorithm is short and straight forward. (And: 
When I implement one of the mentioned algorithms, it can still 
contain bugs, because I made a mistake somewhere.)

More information about the Digitalmars-d mailing list