Andrei Alexandrescu wrote:
> On 6/22/12 7:41 AM, Don Clugston wrote:
> >I think the main thing that's still done in C is the floating point formatting.
> 
> Would be great if a contributor could translate FP parsing and formatting code into D. Then we can use it in CTFE. I need it badly for some function tabulation code.

I think formatting cannot be done such that it is CTFE-able. I tried implementing a less-inefficient version. As far as I can tell at some point you need to extract the significand and the exponent. This is done by some "unsafe" cast which is not allowed in CTFE. I don't know a way to do it in CTFE-compatible way.

Jens

Paulo Pinto:

> as Metro is also native code.

Are you sure? Do you have a reference on this?

Bye,
bearophile

On 28/06/12 15:31, Jens Mueller wrote:
> Andrei Alexandrescu wrote:
>> On 6/22/12 7:41 AM, Don Clugston wrote:
>>> I think the main thing that's still done in C is the floating point
>>> formatting.
>>
>> Would be great if a contributor could translate FP parsing and
>> formatting code into D. Then we can use it in CTFE. I need it badly
>> for some function tabulation code.
>
> I think formatting cannot be done such that it is CTFE-able. I tried
> implementing a less-inefficient version. As far as I can tell at some
> point you need to extract the significand and the exponent. This is done
> by some "unsafe" cast which is not allowed in CTFE. I don't know a way
> to do it in CTFE-compatible way.
>
> Jens

Yeah, I think I will have to find a way of allowing it. But it's difficult to see a clean way of doing it.

Don Clugston wrote:
> On 28/06/12 15:31, Jens Mueller wrote:
> >Andrei Alexandrescu wrote:
> >>On 6/22/12 7:41 AM, Don Clugston wrote:
> >>>I think the main thing that's still done in C is the floating point formatting.
> >>
> >>Would be great if a contributor could translate FP parsing and formatting code into D. Then we can use it in CTFE. I need it badly for some function tabulation code.
> >
> >I think formatting cannot be done such that it is CTFE-able. I tried implementing a less-inefficient version. As far as I can tell at some point you need to extract the significand and the exponent. This is done by some "unsafe" cast which is not allowed in CTFE. I don't know a way to do it in CTFE-compatible way.
> >
> >Jens
> 
> Yeah, I think I will have to find a way of allowing it. But it's difficult to see a clean way of doing it.

Good luck! I'm looking forward to your solution.

Jens

On Thursday, 28 June 2012 at 14:02:37 UTC, Jens Mueller wrote:
> Good luck! I'm looking forward to your solution.
>
> Jens

I think just exposing them via .sig and .exp might be the way to go?

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

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

Andrei

On 06/28/2012 04:35 PM, 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
>
> Andrei

Imho, it should be either

.mantissa and .exponent

or

.mant and .exp

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

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.

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.

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!)
Would it include the implicit bit of an 80-bit x87 real (the silly bit)?