Don Clugston wrote: > On 28/06/12 17:00, Jens Mueller wrote: > >Andrei Alexandrescu wrote: > >>On 6/28/12 10:07 AM, Roman D. Boiko wrote: > >>>On Thursday, 28 June 2012 at 14:04:37 UTC, Mehrdad wrote: > >>>>I think just exposing them via .sig and .exp might be the way to go? > >>> > >>>sig is easy to confuse with sign > >> > >>.mantissa and .exp > > > >Letting the compiler define these properties is a solution. I thought > >Don is looking for something more general. But maybe this isn't needed > >here. Don't know. But using mantissa should be discouraged. > >I suggest calling them > >.significand and .exponent > > > >significand is preferred over mantissa by IEEE FP committee. I think > >it's fine to spell them out. There won't be much code using them anyway. > > > >Jens > > > Yes, adding new properties would be the easiest way from a CTFE > perspective; that way, they are endian-ness independent. It's a bit > niche, but then again adding a special case for this in CTFE is > niche as well. Maybe it would be the best approach.
Sounds good then. > With naming, I'm included to agree, but the funny thing is that we > have X.mant_dig as the number of digits in the significand. You could add a deprecated alias to X.mant_dig and provide a new name. We should adopt IEEE's vocabulary where possible. > There's an oddity, though: the type of X.significand would be > dependent on the type of X (and for the non-existent quadruple > float, it would be non-existent ucent type!) But this is no problem, is it? > Would it include the implicit bit of an 80-bit x87 real (the silly bit)? Not sure what the silly bit is. You mean the bit that is implicitly always 1, don't you? mant_dig says 24 for a float. Means it is included when counting the bits. Then for consistency it should be included. Jens