Date: Tue, 29 Apr 2025 20:14:55 +0000
Yeah, I can help.
It’s relatively easy for me to come up with a reference implementation since I have already explored this problem space.
Regarding “additional alternatives” to handle multiple forms of decimal separators ways of representing exponent, I would advise against it, just provide a view of where the units digits are and where the decimal digits are and the algorithm doesn’t even have to know what you use for decimal separator and how many characters there is, otherwise you end-up with 20 different variants.
A user can very easily write a parser that identifies where boundaries of the digits are, that is not the hard part of the algorithm, so just let the user write that part themselves and solve whatever those details are and we take care of the rest.
From: Jan Schultke <janschultke_at_[hidden]>
Sent: Tuesday, April 29, 2025 10:14 AM
To: Tiago Freire <tmiguelf_at_hotmail.com>
Cc: std-proposals_at_[hidden]
Subject: Re: [std-proposals] Low-level float parsing functions
I think the best approach would be to propose the minimal interface, and then multiple levels of convenience on top of that, and see what LEWG is comfortable with.
* Level 0 would be the function I've shown, just taking the integer and fraction digits, and the pre-parsed exponent.
* Level 1 would additionally take the exponent digits and sign, in case the user doesn't want to preparse the exponent.
* Level 2 would additionally take a character which is ignored anywhere, to enable digit separators
I'm not sure where leading sign characters would come in, or if they're worth supporting at all. The user can just as easily call std::copysign afterwards as passing the sign into std::parse_float, so it appears to be of no value.
There are a few adjacent problems, like making the thing constexpr, but that should be done in sync with making std::from_chars constexpr, and it's a separate issue. Supporting char8_t, char16_t, and char32_t are also adjacent issues and should be done in sync with std::from_chars.
Anyhow, if you'd like to co-author, I'd be happy with that. I'll send some more details by the end of the week.
It’s relatively easy for me to come up with a reference implementation since I have already explored this problem space.
Regarding “additional alternatives” to handle multiple forms of decimal separators ways of representing exponent, I would advise against it, just provide a view of where the units digits are and where the decimal digits are and the algorithm doesn’t even have to know what you use for decimal separator and how many characters there is, otherwise you end-up with 20 different variants.
A user can very easily write a parser that identifies where boundaries of the digits are, that is not the hard part of the algorithm, so just let the user write that part themselves and solve whatever those details are and we take care of the rest.
From: Jan Schultke <janschultke_at_[hidden]>
Sent: Tuesday, April 29, 2025 10:14 AM
To: Tiago Freire <tmiguelf_at_hotmail.com>
Cc: std-proposals_at_[hidden]
Subject: Re: [std-proposals] Low-level float parsing functions
I think the best approach would be to propose the minimal interface, and then multiple levels of convenience on top of that, and see what LEWG is comfortable with.
* Level 0 would be the function I've shown, just taking the integer and fraction digits, and the pre-parsed exponent.
* Level 1 would additionally take the exponent digits and sign, in case the user doesn't want to preparse the exponent.
* Level 2 would additionally take a character which is ignored anywhere, to enable digit separators
I'm not sure where leading sign characters would come in, or if they're worth supporting at all. The user can just as easily call std::copysign afterwards as passing the sign into std::parse_float, so it appears to be of no value.
There are a few adjacent problems, like making the thing constexpr, but that should be done in sync with making std::from_chars constexpr, and it's a separate issue. Supporting char8_t, char16_t, and char32_t are also adjacent issues and should be done in sync with std::from_chars.
Anyhow, if you'd like to co-author, I'd be happy with that. I'll send some more details by the end of the week.
Received on 2025-04-29 20:14:58