This has been discussed in the past and at a point Walter was looking into it.

Currently std.conv.to applied to double uses snprintf, which is obviously non-CTFEable.

There's been recent work (also discussed here) on fast accurate printing of floating point values, see library "double-conversion" written in C++ and the associated paper http://www.cs.tufts.edu/~nr/cs257/archive/florian-loitsch/printf.pdf.

Implementing that in D would be awesome because there are many many applications of CTFEing doubles converted to text.


Andrei

On Wednesday, 16 December 2015 at 15:44:45 UTC, Andrei Alexandrescu wrote:
> This has been discussed in the past and at a point Walter was looking into it.
>
> Currently std.conv.to applied to double uses snprintf, which is obviously non-CTFEable.
>
> There's been recent work (also discussed here) on fast accurate printing of floating point values, see library "double-conversion" written in C++ and the associated paper http://www.cs.tufts.edu/~nr/cs257/archive/florian-loitsch/printf.pdf.
>
> Implementing that in D would be awesome because there are many many applications of CTFEing doubles converted to text.
>
>
> Andrei

If the purpose is to make it CTFEable, then we need to make it work at first. So, there
is no need to focus on fast accurate implementation. I will try to implement it by
multiplication and modulus operations at compile time. But I am not sure about how long the decimal part (I don't know what the part after point is called) should be. Would it be acceptable if it becomes 100 digits in string? What is the limit?

On 12/16/2015 12:04 PM, tcak wrote:
> On Wednesday, 16 December 2015 at 15:44:45 UTC, Andrei Alexandrescu wrote:
>> This has been discussed in the past and at a point Walter was looking
>> into it.
>>
>> Currently std.conv.to applied to double uses snprintf, which is
>> obviously non-CTFEable.
>>
>> There's been recent work (also discussed here) on fast accurate
>> printing of floating point values, see library "double-conversion"
>> written in C++ and the associated paper
>> http://www.cs.tufts.edu/~nr/cs257/archive/florian-loitsch/printf.pdf.
>>
>> Implementing that in D would be awesome because there are many many
>> applications of CTFEing doubles converted to text.
>>
>>
>> Andrei
>
> If the purpose is to make it CTFEable, then we need to make it work at
> first. So, there
> is no need to focus on fast accurate implementation.

This strategy may be a bit risky because then we have slightly different numbers at compile vs. run time etc.

> I will try to
> implement it by
> multiplication and modulus operations at compile time. But I am not sure
> about how long the decimal part (I don't know what the part after point
> is called) should be. Would it be acceptable if it becomes 100 digits in
> string? What is the limit?

Probably mimicking what to does right now would be a good baseline.


Andrei

On 12/16/2015 06:04 PM, tcak wrote:
> On Wednesday, 16 December 2015 at 15:44:45 UTC, Andrei Alexandrescu wrote:
>> This has been discussed in the past and at a point Walter was looking
>> into it.
>>
>> Currently std.conv.to applied to double uses snprintf, which is
>> obviously non-CTFEable.
>>
>> There's been recent work (also discussed here) on fast accurate
>> printing of floating point values, see library "double-conversion"
>> written in C++ and the associated paper
>> http://www.cs.tufts.edu/~nr/cs257/archive/florian-loitsch/printf.pdf.
>>
>> Implementing that in D would be awesome because there are many many
>> applications of CTFEing doubles converted to text.
>>
>>
>> Andrei
>
> If the purpose is to make it CTFEable, then we need to make it work at
> first. So, there
> is no need to focus on fast accurate implementation. I will try to
> implement it by
> multiplication and modulus operations at compile time. But I am not sure
> about how long the decimal part (I don't know what the part after point
> is called) should be. Would it be acceptable if it becomes 100 digits in
> string? What is the limit?

Conversion of string to double should yield the double that has the lowest absolute error. If this is ambiguous, the current rounding mode determines the result.

Conversion of double to string should yield a shortest possible string that when converted to double according to the above procedure gives back the original value.