Date: Thu, 1 May 2025 10:08:56 +0000
FYI.
Here's a link for that algorithm: https://github.com/tmiguelf/utilities/blob/345421be243b7b6a6e70988a77422b5a0b1fe0a1/CoreLib/src/string/fp_charconv_from_chars.cpp#L62C27-L62C47
-----Original Message-----
From: Std-Proposals <std-proposals-bounces_at_lists.isocpp.org> On Behalf Of Jan Schultke via Std-Proposals
Sent: Thursday, May 1, 2025 11:54 AM
To: Jonathan Wakely <cxx_at_[hidden]>
Cc: Jan Schultke <janschultke_at_googlemail.com>; std-proposals_at_lists.isocpp.org
Subject: Re: [std-proposals] Low-level float parsing functions
Sure, but 1.01 is the same as 101e-2. For all intents and purposes, you can treat the digit sequences of integer and fraction as one big integer, and merely adjust the exponent based on where the radix point is located.
I'm also not suggesting parse_float(10, 1, -1) at the lowest API level. The initial step in fast_float is to compute a single uint64_t for the mantissa, and this is something the user can do if they just want this part of the library, so they would be passing something
like:
> parse_float(uint64_t(101) << (63-7), 1).
Although this still requires filling up the lower bits of the mantissa, since .101 cannot be represented in a binary float. I'd have to dig a bit more into how fast_float does it, but what I do know is that after the first stage of the problem, it just has a uint64_t mantissa.
It's not even float parsing at that point anymore; it's really just an exponentiation with 10 to the power of the exponent, and that is the really hard part which makes up the vast majority of fast_float code.
And as I've said, you would build multiple levels of wrappers around that, so the user wouldn't need to touch it usually and could pass string_view digit sequences instead. Taking two integers as parameters would be a weird half measure that makes no sense. There is no level of abstraction between having the uint64_t mantissa and having two char sequences which makes sense.
--
Std-Proposals mailing list
Std-Proposals_at_[hidden]
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
Here's a link for that algorithm: https://github.com/tmiguelf/utilities/blob/345421be243b7b6a6e70988a77422b5a0b1fe0a1/CoreLib/src/string/fp_charconv_from_chars.cpp#L62C27-L62C47
-----Original Message-----
From: Std-Proposals <std-proposals-bounces_at_lists.isocpp.org> On Behalf Of Jan Schultke via Std-Proposals
Sent: Thursday, May 1, 2025 11:54 AM
To: Jonathan Wakely <cxx_at_[hidden]>
Cc: Jan Schultke <janschultke_at_googlemail.com>; std-proposals_at_lists.isocpp.org
Subject: Re: [std-proposals] Low-level float parsing functions
Sure, but 1.01 is the same as 101e-2. For all intents and purposes, you can treat the digit sequences of integer and fraction as one big integer, and merely adjust the exponent based on where the radix point is located.
I'm also not suggesting parse_float(10, 1, -1) at the lowest API level. The initial step in fast_float is to compute a single uint64_t for the mantissa, and this is something the user can do if they just want this part of the library, so they would be passing something
like:
> parse_float(uint64_t(101) << (63-7), 1).
Although this still requires filling up the lower bits of the mantissa, since .101 cannot be represented in a binary float. I'd have to dig a bit more into how fast_float does it, but what I do know is that after the first stage of the problem, it just has a uint64_t mantissa.
It's not even float parsing at that point anymore; it's really just an exponentiation with 10 to the power of the exponent, and that is the really hard part which makes up the vast majority of fast_float code.
And as I've said, you would build multiple levels of wrappers around that, so the user wouldn't need to touch it usually and could pass string_view digit sequences instead. Taking two integers as parameters would be a weird half measure that makes no sense. There is no level of abstraction between having the uint64_t mantissa and having two char sequences which makes sense.
--
Std-Proposals mailing list
Std-Proposals_at_[hidden]
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
Received on 2025-05-01 10:09:00