-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support different bases #75
Comments
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. |
Seems reasonable.
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
I agree that this should be a follow-up proposal, but adding one base for each proposal seems inefficient. Why not just support |
Just to follow up here with the status quo, as of writing: We'll be rolling with IEEE 754 Decimal128 as the underlying data model for decimals. We were debating for a while about different data models, or whether we want something adjacent, such as rational numbers. In the end, we do want to go with decimal numbers. And IEEE 754 Decimal128 is a nice standard to use. Indeed, one can lean on C and C++ compiler support for (part of) that standard, and there's conceivably also hardware support for Decimal128. But this closes the door to providing support for arbitrary bases, I'm afraid. If you're interested in pursuing these ideas, perhaps consider making a proposal? I suppose one requirement would be to surface some use cases for non-binary, non-decimal bases. |
Summary
pros
cons
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 coercionsand 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 ofBigNum
s 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"
Rational
s keep the precision of any fraction because they are independent of any base.BigFloat
s could be seen asRational
s whose denominator is constrained to be integer powers of some base (usually 2). But the reason I'm suggesting this forBigDecimal
is performance. The radix-agnosticism of rationals comes at the cost of calculating GCDs and LCMs, the equivalent operations onBigFloat
s 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
The text was updated successfully, but these errors were encountered: