On 28/06/12 18:36, Jens Mueller wrote:
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.

Yes, the implicit bit. For float and double it isn't present, but it's there for 80bit x87 and 68K reals. But it would not be present for quadruple types. I'm not sure if it's always present on Itanium 80-bit reals.

It's included in the 80-bit reals only for historical reasons -- it seemed like a good idea at the time. It allowed an optimisation for a long-obsolete algorithm.

Reply via email to