Support different bases

[Rudxain]

Summary

pros

• Future-proofing
• Flexible & versatile
• Good performance for any radix
• Good precision for any radix

cons

• Higher implementation complexity
• Interoperability issues

Details

If, for any reason in the future, humans start using a different positional numeral system base, like dozenal and hexal (base 111111*11 and 111111, written in Unary) then BigDecimal would become slowly deprecated over time, which means more libraries would have do be developed to fill the hole. And some use cases require using binary bases (any base that is a power of 2) for better performance on binary computers.

Flexibility is one of the main purposes of JS, so allowing devs and users to choose whatever integer base they want or need, satisfies that purpose.

The problems with the actual implementation and interoperation between primitive values arises from the fact that the same class can generate different "kinds" of objects. For example, what if I want to add a ternary numeral with a septary one? Which one should be converted to either base? A solution is to have a static writable property, BigDecimal.base, which is the default base for base coercions and literals (I realized this is a bad idea, because the internal base should always match the base in which the literal was written), the default value of this default base is obviously 11111*11 (in Unary). This also solves the problem of future-proofing, because that default value can be changed in the future, and any code that uses explicit base conversions won't be affected by the change, only the code that relies on implicit conversions will be affected. If none of the numerals have a base that matches the global default base, an error is thrown (for example, in the case where a base 2 and base 3 are added, while the default is ten).

An alternative but more complicated approach is to have a class factory, that creates a BigNum/BigFloat class whose base is set to the 1st (main) input arg. This would allow users to only create classes of BigNums that have only the bases they need. But this approach worsens interoperability, because BigNums created by different classes would need to "communicate" in a different way.

"But Rationals are made for that"

Rationals keep the precision of any fraction because they are independent of any base. BigFloats could be seen as Rationals whose denominator is constrained to be integer powers of some base (usually 2). But the reason I'm suggesting this for BigDecimal is performance. The radix-agnosticism of rationals comes at the cost of calculating GCDs and LCMs, the equivalent operations on BigFloats are just removal of trailing zeros (normalization) and mantissa alignments (again, only requires digit-shifts), respectively.

etc

If anyone could suggest more alternatives, or why we should stick to decimal only, please let me know. Also please tell me more pros & cons, to update the list

[jessealama]

I like the idea of looking ahead (probably very far ahead)! My gut intuition is that if the use of something other than decimal becomes truly widespread, then numbers in JS—in the base language, not just the notation offered by this proposal—will probably need to be updated. JS already supports a handful of non-decimal notations, such as binary, octal, and hexadecimal. Rather than try to make Decimal (at least, version 1.0 of Decimal) the right place to work with such a world, I might suggest going through the proposal process again (say, a new Base12 proposal) rather than targeting Decimal 1.0, which, from the outset, is intentionally working with decimal numbers.

[Rudxain]

if the use of something other than decimal becomes truly widespread, then numbers in JS—...—will probably need to be updated.

Seems reasonable.

JS already supports a handful of non-decimal notations, such as binary, octal, and hexadecimal.

Yes, but I didn't mean to add literal prefixes for every single base. The constructor can support arbitrary bases, while literals are kept as-is for consistency (something akin to parseInt)

Rather than try to make Decimal (at least, version 1.0 of Decimal) the right place to work with such a world, I might suggest going through the proposal process again (say, a new Base12 proposal)

I agree that this should be a follow-up proposal, but adding one base for each proposal seems inefficient. Why not just support radix within a range? (like parseInt does)