text.convert.Format needs to support 80-bit reals

Yeah. I'm hoping for some guidance on this from yourself, Don? There's the 'performance' questionmark, and the portability thing too? Additionally, and perhaps more importantly, the algorithms used for both parsing and formatting FP numbers could use some critical review.

Yes, I'm just not yet familiar enough with the way Mango I/O works. I'm a little confused by the code duplication in Double.d and Format.d, in my initial investigation I couldn't work out the relationship between the two. Once I get the meta.Nameof stuff under control, I'll get onto this.

I'll take over this one.

Oops, I certainly can't do this, especially since my previous changes were removed. This formatting of FP numbers is a real mess at the moment.

Yeah, I agree.

DGDouble will go, and the stuff in Formatter will get folded (somehow) with the code in Double. I suspect we need to update the code in Double to be the de-facto converter for Tango, and perhaps base it on real rather than double. This will probably require a review of how effective the code in Formatter is -- a different algorithm altogether.

I don't have the skills to do a critical review (though I can write the stuff), so this is where I'd hoped you could help out ...

That makes sense to me. I still don't have a very good understanding of Mango IO. Might be better to call the module Float instead of Double (?) The minimal approach would be to just link to the C library's long double ecvt and fcvt, to get the functionality in place, and then look at replacing it with D code. (Interesting quirky fact: the reason why 80-bit reals originally existed was so that a naive implementation of fp <-> decimal conversion would be correct for most normal 'double' values).

Localisation of FP is an interesting issue. I don't think it should involve anything more than the decimal point indicator. I propose: * Follow IEEE 754r and display infinity as +Inf, -Inf, regardless of language, and display NaN as NaN (regardless of sign). * Seperating numbers into comma-seperated groups is generally undesirable in scientific contexts.

I won't have much D time available before 1.0, so probably won't be able to contribute much, but should be able to do some review.

thanks!

80bit is implemented, but I'm still not sure the best way to do hex support. Looking into %A

Splitting this ticket into 2. The 80bit stuff was done for last release