Jump to page: 1 2
Thread overview
now it's possible! printing floating point numbers at compile-time
Dec 22
Basile B.
Dec 30
0xEAB
Dec 28
ketmar
Dec 30
ketmar
Dec 30
Basile B.
Dec 30
ketmar
Dec 30
ketmar
December 22
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


December 22
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

December 22
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
December 22
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.


December 27
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.
December 28
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
December 30
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
December 30
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! ;-)
December 30
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...
December 30
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).
« First   ‹ Prev
1 2