Potential use case: Radix conversion for exact double-to-decimal

[sffc]

An IEEE 754 binary floating-point number is represented as an integer significand raised to a binary base (2^e). In order to convert a double to a decimal, a radix conversion from base 2 to base 10 is required. The exact conversion requires math that exceeds the capacity of fixed-width integer types.

Some additional reading describing the double-to-decimal conversion process:

• https://lists.nongnu.org/archive/html/gcl-devel/2012-10/pdfkieTlklRzN.pdf
• https://www.cs.tufts.edu/~nr/cs257/archive/florian-loitsch/printf.pdf
• https://dl.acm.org/doi/pdf/10.1145/3192366.3192369

[jakobkummerow]

https://www.cs.tufts.edu/~nr/cs257/archive/florian-loitsch/printf.pdf

That paper describes the algorithm that (at least) V8, SpiderMonkey, and WebKit are using for Number.toString(); in fact the implementation was created by the author of that paper. I don't see why anyone would want to reimplement in JavaScript what the engine already provides, so as a corollary I don't think it constitutes much of a use case for any new features.

[js-choi]

Thanks, @sffc, for leaving these links after August’s TC39 meeting. Although @jakobkummerow has a point that these essentially are equivalent to Number.prototype.toString, it is still good to know as many theoretical use cases as possible.

[sffc]

https://www.cs.tufts.edu/~nr/cs257/archive/florian-loitsch/printf.pdf

That paper describes the algorithm that (at least) V8, SpiderMonkey, and WebKit are using for Number.toString(); in fact the implementation was created by the author of that paper. I don't see why anyone would want to reimplement in JavaScript what the engine already provides, so as a corollary I don't think it constitutes much of a use case for any new features.

The algorithm implemented in Number.prototype.toString is a specialized case of the full radix conversion operation. However, this is not the full-precision radix conversion that requires BigInt math.
The full-precision radix conversion is available in Number.prototype.toFixed:

(1.03).toFixed(100)
// "1.0300000000000000266453525910037569701671600341796875000000000000000000000000000000000000000000000000"

Thanks, @sffc, for leaving these links after August’s TC39 meeting. Although @jakobkummerow has a point that these essentially are equivalent to Number.prototype.toString, it is still good to know as many theoretical use cases as possible.

I agree that since this is built into browsers, it's not necessary to implement in userland. I was primarily opening this issue to highlight the fact that radix conversion is a foundational operation that would make sense to have in a BigInt math library, with double-to-decimal being an application of that operation.

[js-choi]

@sffc: To continue your train of thought, do you happen to think that a generic radix-conversion method would be useful to add to Math or perhaps Number/BigInt? If so, would you have any use cases to which you could point?

(Either way, I think that would probably be out of scope of this particular proposal, but it would be good to know for the future anyway.)

Also, just to make sure I’m understanding your reference to Steele and White (1990), their algorithm basically would use arithmetic, floor, and negative powers / roots over BigInts, right? So someone should be able to reimplement it with the extensions in this proposal alone. Though perhaps it’s moot now with Grisu and Ryū anyway…

[sffc]

@sffc: To continue your train of thought, do you happen to think that a generic radix-conversion method would be useful to add to Math or perhaps Number/BigInt? If so, would you have any use cases to which you could point?

I think radix conversions to/from String would be useful, as suggested in #12.

Also, just to make sure I’m understanding your reference to Steele and White (1990), their algorithm basically would use arithmetic, floor, and negative powers / roots over BigInts, right? So someone should be able to reimplement it with the extensions in this proposal alone. Though perhaps it’s moot now with Grisu and Ryū anyway…

All of the papers I listed in the OP are optimizations to avoid the full expensive radix conversion.