Improve display

[ajtribick]

Current implementation of display is very basic, more options would be useful!

[ChristopherRabotin]

I've done some very initial work on this branch: https://github.com/ChristopherRabotin/twofloat/tree/1-improve-display .
Almost all of it is taken from qd. That library includes a macro to quickly create a new double-double: dd!(12.3654789). Would you be open to that? Would you prefer it called tf! for two floats?

[ajtribick]

Thanks a lot! I will take a look at that. I definitely agree that having a macro for moving the parsing to compile time makes sense. I've been doing most of the work for the next version in the v0.5-dev branch, so it would make most sense to use that as the base for your branch.

[ChristopherRabotin]

Nice looking changes on the 0.5-dev branch!

How would you prefer the Display to be implemented? Would you like it to have a human understandable notation (like an f64) or would you like to keep the hi+lo formatting like it is today?

[ajtribick]

I think it would make sense to implement it as human-understandable, that way it should be compatible with the parser I've already put into 0.5-dev. A few months back I had been taking a look at how Dragon4 works in order to see if it would be possible to adapt it to get a shortest unique representation but hadn't got round to sitting down to implement it.

[ChristopherRabotin]

Oh, I don't know about the Dragon4 algorithms. There's a 2010 paper by Florian Loitsch, available at the very bottom of this page, titled "Printing Floating-Point Numbers Quickly and Accurately with Integers." Is there another reference you know of?

[ajtribick]

The main reference I was looking at was the Steele & White (1990) one (linked from this page, which looked relatively promising to adapt, particularly since I'm already using big rationals to do the parsing side of things. My understanding is that the Grisu3 algorithm from the Loitsch paper sometimes requires falling back to something like the Dragon4 algorithm for some number of cases, so figured that it would make sense to start with just Dragon4, with the option of doing something more like Grisu3 (assuming it translates to double-doubles) if such optimisations become necessary.

[ChristopherRabotin]

Ooof, any idea where there is a cached version of that page? The username has disappeared.

Edit. There's a PDF here: https://lists.nongnu.org/archive/html/gcl-devel/2012-10/pdfkieTlklRzN.pdf

Edit 2: Just want to take the opportunity to thank you a ton for the great work on this crate! Using it as the baseline for hifitime led to an 85 to 90% speed improvement according to cargo bench.

[ChristopherRabotin]

Off the cuff, would summing both hi and lo and printing that as a single f64 (with all the options of f64) work? It seems like a low hanging fruit solution. What do you think?