www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - now it's possible! printing floating point numbers at compile-time

reply Stefan Koch <uplink.coder googlemail.com> writes:
Hi Guys,

during my research on floating point numbers I came across a 
short and efficient implementation[0] of the grisu2 algorithm for 
converting floating point numbers into strings.

Which I then ported into CTFEable D code.
Thus enabling you to convert doubles into strings at compiletime.

Cheers

Stefan Koch

P.S. You can find it at my fork of fpconv[1].


[0] https://github.com/night-shift/fpconv
[1] 
https://github.com/UplinkCoder/fpconv/blob/master/src/fpconv_ctfe.d
Dec 22 2018
next sibling parent reply Stefan Koch <uplink.coder googlemail.com> writes:
On Saturday, 22 December 2018 at 20:08:12 UTC, Stefan Koch wrote:

 Thus enabling you to convert doubles into strings at 
 compiletime.


Aww .... I am dumb ... should have waited 2 days :)
Anyhow I hope that this is helpful to some of you.

Please note that grisu 2 will give you representation which will 
convert into the same(!) floatingpoint number you passed in >92% 
of all possible inputs.

Meaning you can round trip from string to double without loss of 
bits, for very many number but not all of them, that said the 
accuracy in general should be better than what a usual sprintf 
would give you.


Cheers and Merry Christmas,

Stefan
Dec 22 2018
parent reply Basile B. <b2.temp gmx.com> writes:
On Saturday, 22 December 2018 at 20:24:46 UTC, Stefan Koch wrote:

 On Saturday, 22 December 2018 at 20:08:12 UTC, Stefan Koch 
 wrote:

 Thus enabling you to convert doubles into strings at 
 compiletime.




Cool, CTFE formating is something that occasionaly comes in the 
forum. Now i remember there's also RYU [1] that could have worked 
too


 Aww .... I am dumb ... should have waited 2 days :)



No because actually from a pagan point of view the big thing was 
yesterday night (solstice).


 Anyhow I hope that this is helpful to some of you.
 Please note that grisu 2 will give you representation which 
 will convert into the same(!) floatingpoint number you passed 
 in >92% of all possible inputs.

 Meaning you can round trip from string to double without loss 
 of bits, for very many number but not all of them, that said 
 the accuracy in general should be better than what a usual 
 sprintf would give you.


 Cheers and Merry Christmas,

 Stefan


[1] https://github.com/ulfjack/ryu
Dec 22 2018
parent Stefan Koch <uplink.coder googlemail.com> writes:
On Saturday, 22 December 2018 at 21:06:48 UTC, Basile B. wrote:

 On Saturday, 22 December 2018 at 20:24:46 UTC, Stefan Koch 
 wrote:

 On Saturday, 22 December 2018 at 20:08:12 UTC, Stefan Koch 
 wrote:

 Thus enabling you to convert doubles into strings at 
 compiletime.




 Cool, CTFE formating is something that occasionaly comes in the 
 forum. Now i remember there's also RYU [1] that could have 
 worked too

 [1] https://github.com/ulfjack/ryu


Thanks for pointing it out, ryu however looks less fast for ctfe 
purposes.
Dec 22 2018
prev sibling next sibling parent reply Nick Treleaven <nick geany.org> writes:
On Saturday, 22 December 2018 at 20:08:12 UTC, Stefan Koch wrote:

 I came across a short and efficient implementation[0] of the 
 grisu2 algorithm for converting floating point numbers into 
 strings.

 Which I then ported into CTFEable D code.
 Thus enabling you to convert doubles into strings at 
 compiletime.


Great! Is the MIT license compatible with Boost? If so I suggest 
we include it in Phobos. I remember Andrei was calling for a 
Grisu port for CTFE some years ago, but I think licensing of 
non-D implementations at the time was an issue.
Dec 27 2018
parent reply 0xEAB <desisma heidel.beer> writes:
On Thursday, 27 December 2018 at 12:46:06 UTC, Nick Treleaven 
wrote:

 Is the MIT license compatible with Boost?


Simply put, no. The MIT license comes with the additional 
requirement of including the copyright notice and license in all 
copies (incl. binary form), whereas BSL-1.0 requires this only 
for source form.

PS: I am not a lawyer.
Dec 30 2018
parent Andre Pany <andre s-e-a-p.de> writes:
On Sunday, 30 December 2018 at 15:14:08 UTC, 0xEAB wrote:

 On Thursday, 27 December 2018 at 12:46:06 UTC, Nick Treleaven 
 wrote:

 Is the MIT license compatible with Boost?


 Simply put, no. The MIT license comes with the additional 
 requirement of including the copyright notice and license in 
 all copies (incl. binary form), whereas BSL-1.0 requires this 
 only for source form.

 PS: I am not a lawyer.


Fantastic news
https://github.com/night-shift/fpconv/blob/master/license

night-shift was so kind to release it under boost license.

Kind regards
Andre
Jan 04 2019
prev sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
Stefan Koch wrote:


 Hi Guys,

 during my research on floating point numbers I came across a short and 
 efficient implementation[0] of the grisu2 algorithm for converting 
 floating point numbers into strings.

 Which I then ported into CTFEable D code.
 Thus enabling you to convert doubles into strings at compiletime.

 Cheers

 Stefan Koch

 P.S. You can find it at my fork of fpconv[1].


 [0] https://github.com/night-shift/fpconv
 [1] https://github.com/UplinkCoder/fpconv/blob/master/src/fpconv_ctfe.d


of course, it is not all that fancy, but i ported STB converter quite a 
long time ago, and it is ctfe-able too. ;-)

[0] https://repo.or.cz/iv.d.git/blob_plain/HEAD:/ctfefloat.d
Dec 28 2018
parent reply Stefan Koch <uplink.coder googlemail.com> writes:
Hi Ketmar, thanks for sharing your work!

On Friday, 28 December 2018 at 19:03:02 UTC, ketmar wrote:

 Stefan Koch wrote:

 [ ... ] [1] 
 https://github.com/UplinkCoder/fpconv/blob/master/src/fpconv_ctfe.d


 of course, it is not all that fancy, but i ported STB converter 
 quite a long time ago, and it is ctfe-able too. ;-)

 [0] https://repo.or.cz/iv.d.git/blob_plain/HEAD:/ctfefloat.d



I've benchmarked it[0] against fpconv_ctfe[1] and yours is almost 
as fast!
However it has a a little more error when converting floats than 
grisu2 has.

Meaning generally the output cannot round-trip.

Warm greetings,

Stefan
Dec 30 2018
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
i think that porting Ryu will get us the fastest one (and with 
smaller/easier code). and without pathological cases of grisu too. too bad 
that i didn't knew about Ryu back than.

as for roundtrips -- you're probably right. stb implementation was made to 
be "mostly correct", afair, but not fully correct. or i broke something 
(which is very possible). it worked for my cases, tho, so i just sticked 
with it.

anyway, two is better than one! ;-)
Dec 30 2018
parent reply Basile B. <b2.temp gmx.com> writes:
On Sunday, 30 December 2018 at 12:19:19 UTC, ketmar wrote:

 too bad that i didn't knew about Ryu back than.


It's very recent, announce on proggit is < 1 year.

It would be nice to have one to format in phobos. RYU or Grisu3 
doesn't matter much as long as the two issues that are

- CTFE formatting of floats
- formatting is identical on all platforms

is solved. There's also the "real" problem. I'm pretty sure that 
32 and 64 bits floats are always handled. Someteimes 128 bits 
ones but not sure for 80 bits...
Dec 30 2018
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
Basile B. wrote:


 On Sunday, 30 December 2018 at 12:19:19 UTC, ketmar wrote:

 too bad that i didn't knew about Ryu back than.


 It's very recent, announce on proggit is < 1 year.

 It would be nice to have one to format in phobos. RYU or Grisu3 doesn't 
 matter much as long as the two issues that are

 - CTFE formatting of floats
 - formatting is identical on all platforms


actually, there is a 3rd issue, which is often overlooked: conversion from 
string to float. to get a perfect roundtrip, this one should be done right too.



 is solved. There's also the "real" problem. I'm pretty sure that 32 and 
 64 bits floats are always handled. Someteimes 128 bits ones but not sure 
 for 80 bits...


80 bits can (usually) be extended to 128. you'll get some extra meaningless 
digits, of course, but it is better than nothing, i think.

actually, Ryu has all the math to derive 80-bit implementation. it will 
require 128-bit integers, though. (less than 128, but there is no sense in 
using smaller ints anyway).
Dec 30 2018
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sun, Dec 30, 2018 at 03:26:33PM +0200, ketmar via Digitalmars-d-announce
wrote:

 Basile B. wrote:
 

 On Sunday, 30 December 2018 at 12:19:19 UTC, ketmar wrote:

 too bad that i didn't knew about Ryu back than.


 
 It's very recent, announce on proggit is < 1 year.
 
 It would be nice to have one to format in phobos. RYU or Grisu3
 doesn't matter much as long as the two issues that are
 
 - CTFE formatting of floats
 - formatting is identical on all platforms


 actually, there is a 3rd issue, which is often overlooked: conversion
 from string to float. to get a perfect roundtrip, this one should be
 done right too.


[...]

Doesn't hex output format (e.g. std.format's %a and %A) already solve
this?  It basically outputs the exact bits in hex. No room for error
there.


T

-- 
It said to install Windows 2000 or better, so I installed Linux instead.
Dec 30 2018
parent ketmar <ketmar ketmar.no-ip.org> writes:
H. S. Teoh wrote:


 actually, there is a 3rd issue, which is often overlooked: conversion
 from string to float. to get a perfect roundtrip, this one should be
 done right too.


 Doesn't hex output format (e.g. std.format's %a and %A) already solve
 this?  It basically outputs the exact bits in hex. No room for error
 there.


it does. but then you can simply go with writing binaries as-is -- they are 
not really less readable than hex floats. ;-) but we want decimals! ;-)
Dec 30 2018