What's the status of to_chars/from_chars for floating-point types?

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

What's the status of to_chars/from_chars for floating-point types?

Ruslan Kabatsayev
Hi all,

The C++17 functions to_chars and from_chars have been implemented for
integer types quite a long time. Until recently, there were no
implementations of their floating-point versions in major compilers.
Now that STL has implemented these functions completely in MSVC, I
wonder what their current status is in GCC.

So, is anyone actively working on it? If not, and no one is planning
to begin soon, I'm considering giving it a try. But first I have some
questions on it:

* What's the expected form of this functionality — should it be a
header-only implementation like the current one for integer types?
* Could it use e.g. some dedicated functions in glibc (possibly
implemented specially for libstdc++ — to take advantage of the
existing codebase for printf), or maybe use libdouble-conversion for
this (it can handle float and double types, not long double though)?
* Does it have to be fully self-contained in libstdc++, so that no
external dependencies would be tolerated?
* Does it have to noticeably outperform printf, or would basically the
same performance be good enough for a start?

Regards,
Ruslan
Reply | Threaded
Open this post in threaded view
|

Re: What's the status of to_chars/from_chars for floating-point types?

Jonathan Wakely-3
On 24/06/19 21:13 +0300, Ruslan Kabatsayev wrote:
>Hi all,
>
>The C++17 functions to_chars and from_chars have been implemented for
>integer types quite a long time. Until recently, there were no
>implementations of their floating-point versions in major compilers.
>Now that STL has implemented these functions completely in MSVC, I
>wonder what their current status is in GCC.

I have an implementation of from_chars for float/double/long double.
Ed Smith-Rowland has said he's going to work on to_chars.

>So, is anyone actively working on it? If not, and no one is planning
>to begin soon, I'm considering giving it a try. But first I have some
>questions on it:
>
>* What's the expected form of this functionality — should it be a
>header-only implementation like the current one for integer types?

No, definitely not.

>* Could it use e.g. some dedicated functions in glibc (possibly
>implemented specially for libstdc++ — to take advantage of the
>existing codebase for printf), or maybe use libdouble-conversion for
>this (it can handle float and double types, not long double though)?

We can't rely on glibc because GCC supports lots of non-GNU targets.

>* Does it have to be fully self-contained in libstdc++, so that no
>external dependencies would be tolerated?

Yes. Any dependencies on an external library need to be handled by
adding the library to libstdc++.

>* Does it have to noticeably outperform printf, or would basically the
>same performance be good enough for a start?

If it doesn't outperform printf then it might as well just be
implemented by calling printf. So I think a non-trivial implementation
that fails to outperform printf is a waste of time.

The state of the art is https://github.com/ulfjack/ryu which also
needs a complete implementation of Dragon4 or Grisu3 for some edge
cases. And if I understand correctly, it doesn't support long double
(and GCC supports multiple different formats for long double,
depending on the target).

Reply | Threaded
Open this post in threaded view
|

Re: What's the status of to_chars/from_chars for floating-point types?

Ruslan Kabatsayev
Hi,

Thanks for your reply.

On Mon, 24 Jun 2019 at 22:17, Jonathan Wakely <[hidden email]> wrote:

>
> On 24/06/19 21:13 +0300, Ruslan Kabatsayev wrote:
> >Hi all,
> >
> >The C++17 functions to_chars and from_chars have been implemented for
> >integer types quite a long time. Until recently, there were no
> >implementations of their floating-point versions in major compilers.
> >Now that STL has implemented these functions completely in MSVC, I
> >wonder what their current status is in GCC.
>
> I have an implementation of from_chars for float/double/long double.
> Ed Smith-Rowland has said he's going to work on to_chars.

Thanks, this is good to know.

>
> >So, is anyone actively working on it? If not, and no one is planning
> >to begin soon, I'm considering giving it a try. But first I have some
> >questions on it:
> >
> >* What's the expected form of this functionality — should it be a
> >header-only implementation like the current one for integer types?
>
> No, definitely not.
>
> >* Could it use e.g. some dedicated functions in glibc (possibly
> >implemented specially for libstdc++ — to take advantage of the
> >existing codebase for printf), or maybe use libdouble-conversion for
> >this (it can handle float and double types, not long double though)?
>
> We can't rely on glibc because GCC supports lots of non-GNU targets.
>
> >* Does it have to be fully self-contained in libstdc++, so that no
> >external dependencies would be tolerated?
>
> Yes. Any dependencies on an external library need to be handled by
> adding the library to libstdc++.
>
> >* Does it have to noticeably outperform printf, or would basically the
> >same performance be good enough for a start?
>
> If it doesn't outperform printf then it might as well just be
> implemented by calling printf. So I think a non-trivial implementation
> that fails to outperform printf is a waste of time.

Actually no, the "shortest representation" requirement can't be
satisfied using only printf (it takes number of digits as input
parameter), some logic must be implemented to find out the number of
digits for each particular value. Though maybe that's what you meant
by trivial — calculate number of digits and call sprintf.

>
> The state of the art is https://github.com/ulfjack/ryu which also
> needs a complete implementation of Dragon4 or Grisu3 for some edge
> cases. And if I understand correctly, it doesn't support long double
> (and GCC supports multiple different formats for long double,
> depending on the target).

Thanks for this, didn't know of this algorithm. From what I read in
the paper, Ryū doesn't need the fallbacks to a slower implementation —
it's only Grisu3 who does. And regarding long double, the GitHub repo
you link to does have 128-bit API and explicit support for 80-bit
(exp15/mant63) floats (see issue #13 there).

Thanks,
Ruslan
Reply | Threaded
Open this post in threaded view
|

Re: What's the status of to_chars/from_chars for floating-point types?

Jonathan Wakely-3
On 25/06/19 15:01 +0300, Ruslan Kabatsayev wrote:
>> If it doesn't outperform printf then it might as well just be
>> implemented by calling printf. So I think a non-trivial implementation
>> that fails to outperform printf is a waste of time.
>
>Actually no, the "shortest representation" requirement can't be
>satisfied using only printf (it takes number of digits as input
>parameter), some logic must be implemented to find out the number of
>digits for each particular value. Though maybe that's what you meant
>by trivial — calculate number of digits and call sprintf.

Yes, that's true, printf alone isn't a valid implementation.

>>
>> The state of the art is https://github.com/ulfjack/ryu which also
>> needs a complete implementation of Dragon4 or Grisu3 for some edge
>> cases. And if I understand correctly, it doesn't support long double
>> (and GCC supports multiple different formats for long double,
>> depending on the target).
>
>Thanks for this, didn't know of this algorithm. From what I read in
>the paper, Ryū doesn't need the fallbacks to a slower implementation —
>it's only Grisu3 who does. And regarding long double, the GitHub repo
>you link to does have 128-bit API and explicit support for 80-bit
>(exp15/mant63) floats (see issue #13 there).

Ah, maybe my information is out of date.

12 months ago Ryu only supported scientific format, so for fixed
format you needed something else. Ryu also couldn't handle outputting
a specified precision, it always stopped at the shortest
representation. And it didn't support hex output.

Maybe that has all been added now, along with support for >64-bit
types.

Reply | Threaded
Open this post in threaded view
|

Re: What's the status of to_chars/from_chars for floating-point types?

Ruslan Kabatsayev
On Tue, 25 Jun 2019 at 15:25, Jonathan Wakely <[hidden email]> wrote:

>
> On 25/06/19 15:01 +0300, Ruslan Kabatsayev wrote:
> >> If it doesn't outperform printf then it might as well just be
> >> implemented by calling printf. So I think a non-trivial implementation
> >> that fails to outperform printf is a waste of time.
> >
> >Actually no, the "shortest representation" requirement can't be
> >satisfied using only printf (it takes number of digits as input
> >parameter), some logic must be implemented to find out the number of
> >digits for each particular value. Though maybe that's what you meant
> >by trivial — calculate number of digits and call sprintf.
>
> Yes, that's true, printf alone isn't a valid implementation.
>
> >>
> >> The state of the art is https://github.com/ulfjack/ryu which also
> >> needs a complete implementation of Dragon4 or Grisu3 for some edge
> >> cases. And if I understand correctly, it doesn't support long double
> >> (and GCC supports multiple different formats for long double,
> >> depending on the target).
> >
> >Thanks for this, didn't know of this algorithm. From what I read in
> >the paper, Ryū doesn't need the fallbacks to a slower implementation —
> >it's only Grisu3 who does. And regarding long double, the GitHub repo
> >you link to does have 128-bit API and explicit support for 80-bit
> >(exp15/mant63) floats (see issue #13 there).
>
> Ah, maybe my information is out of date.
>
> 12 months ago Ryu only supported scientific format, so for fixed
> format you needed something else. Ryu also couldn't handle outputting
> a specified precision, it always stopped at the shortest
> representation. And it didn't support hex output.

Currently, scientific format is supported, fixed is too, and even
precision can be specified, BUT: Ryū is in principle incapable of
emitting true large-precision digits, since the algorithm was designed
to avoid long arithmetic. Currently the space for extra precision
digits is simply padded with zeros. For mathematically correct
implementation of the precision-driven overloads of to_chars one would
have to have separate code (did you mean this to be the edge case?).
And hexfloat is so trivial due to being exact that I don't think it
even has to be in that repo.

>
> Maybe that has all been added now, along with support for >64-bit
> types.
>