search

tc39 / proposal-bigint-math

Draft specification for supporting BigInts in JavaScript’s Math methods.
https://tc39.es/proposal-bigint-math/
BSD 3-Clause "New" or "Revised" License
36 stars 2 forks source link

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

Closed sffc closed 2 years ago

sffc commented 2 years ago

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:

jakobkummerow commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

@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 commented 2 years ago

@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.