Add f2fixed() and f2exp()?

[StephanTLavavej]

ryu/ryu/d2fixed.c

Line 395 in a73883c

int d2fixed_buffered_n(double d, uint32_t precision, char* result) {

and

ryu/ryu/d2fixed.c

Line 597 in a73883c

int d2exp_buffered_n(double d, uint32_t precision, char* result) {

take 64-bit double but work with 32-bit float (because float can be losslessly widened to double; note that this is untrue for string-to-floating conversions, where rounding a string to a double and rounding again to a float is a subtle mistake).

Would dedicated 32-bit implementations be even faster, possibly by using narrower multiplications? Like how

ryu/ryu/f2s.c

Line 154 in a73883c

static inline floating_decimal_32 f2d(const uint32_t ieeeMantissa, const uint32_t ieeeExponent) {

is faster than

ryu/ryu/d2s.c

Line 238 in a73883c

static inline floating_decimal_64 d2d(const uint64_t ieeeMantissa, const uint32_t ieeeExponent) {

[StephanTLavavej]

Data point: charconv's shortest fixed notation overload benefits from calling d2fixed_buffered_n() for large exactly-representable integer doubles, but not for floats. On x86, the long division technique on uint32_t[4] is significantly faster (71.4 ns versus 101.1 ns, end-to-end cost averaged over all inputs). On x64, long division is very slightly faster (51.4 ns versus 52.1 ns). As a result I'll continue using long division for float, unless/until f2fixed() is implemented.

[ulfjack]

Please refrain from shouting here. Also, if you have proposals for how to improve C++, this isn't really the right place to discuss them.