digitalmars.D - Another cool project: make double.to!string CTFEable
- Andrei Alexandrescu (11/11) Dec 16 2015 This has been discussed in the past and at a point Walter was looking
- tcak (10/21) Dec 16 2015 If the purpose is to make it CTFEable, then we need to make it
- Andrei Alexandrescu (5/31) Dec 16 2015 This strategy may be a bit risky because then we have slightly different...
- Timon Gehr (7/32) Dec 16 2015 Conversion of string to double should yield the double that has the
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
Dec 16 2015
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. AndreiIf 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?
Dec 16 2015
On 12/16/2015 12:04 PM, tcak wrote:On Wednesday, 16 December 2015 at 15:44:45 UTC, Andrei Alexandrescu wrote:This strategy may be a bit risky because then we have slightly different numbers at compile vs. run time etc.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. AndreiIf 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?Probably mimicking what to does right now would be a good baseline. Andrei
Dec 16 2015
On 12/16/2015 06:04 PM, tcak wrote:On Wednesday, 16 December 2015 at 15:44:45 UTC, Andrei Alexandrescu wrote: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.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. AndreiIf 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?
Dec 16 2015