If Decimal128 is supported, should those methods and options be added to `Number`?

[dead-claudia]

Given Decimal128 is in terms of IEEE-754 decimal128 and Number is in terms of IEEE-754 binary64, I feel it'd make sense to extend these methods to that for consistency.

This of course is more a suggestion for a follow-on, and also some food for thought (it raises questions on rounding mode handling in general).

[munrocket]

Thanks for this issue! I am thinking that we need to expose scalar FMA in the web according to IEEE-754 with slow but correctly rounded version if it not supported in processor

let x = Math.fma(a, b, c);

In this way we can implement binary arbitrary floating point in user space libraries insanely fast in most of devices, I have done proposal in tc39 discourse https://es.discourse.group/t/math-float-optimisation/829/14 but not sure that I have good explanation there why we need it.

{ round: "up/down/0/ne” } mode from future Decimal inside Number can be useful, as I know it also can be done with this basic functions (like in Java)

let successor = Math.nextUp(x);
let predecessor = Math.nextDown(x)

[sarahghp]

@isiahmeadows I am not certain I understand which methods you are referring to in the original post? Could you elaborate a bit more about the methods and how they make sense with the Decimal proposal?

[dead-claudia]

@sarahghp I'm referring to these, which lack any corresponding Number equivalent:

• Decimal128.round(decimal, options)
• Decimal128.div(a, b, options)
• Decimal128.pow(decimal, number, options)
• Decimal128.partition(decimal, pieces, roundingOptions)

Of these, div and pow do have equivalents without options, but not with options. This is why I brought it up.

@munrocket That would be better suited for https://github.com/rwaldron/proposal-math-extensions or https://github.com/phoddie/integer-and-modulus-math-proposal (it's stage 1, just the README needs updated).