Comparisons

[waldemarhorwat]

I can't find compare_total in my copy of IEEE 754, and, amazingly, a Google search returns nothing at all for IEEE 754 compare_total. Nor do I see it in the list of recent changes to IEEE 754. I assume this is referring to the totalOrder operation in the standard?

The total order predicate has technically challenging semantics and radically differs from how ==, ===, <, etc. behave on Numbers. Folks trying to use the total order version of < will experience serious surprises unless they're advanced numeric experts.

At the very least we should define the total order operation as a separately named function, rather than sticking it as a mode on comparisons. Preferably we should omit it altogether from the first version of Decimal. It would be odd to include an IEEE operation that's so obscure that we don't even provide it on Numbers. Providing Decimal exponentials and such should be a higher priority.

[littledan]

Yes, I'd be happy to omit this function too. We might want to add a SameValue-like equality comparison operator (could be a separate name), but I'm not convinced about the need for this linear order either.

[jessealama]

Right, the current intention is to model IEEE 754's compare_totalAKA totalCompare as the default way to do comparisons, with compare available as a separate mode.

I'm not sure I understand why compare_total would be more technically challenging. For me, compare_total is more natural than compare because compare_total enables the programmer to think of Decimal objects as mathematical values, whereas with compare one needs to think of digit strings. The current thinking is to enable JS programmers to think of Decimal objects as mathematical values.

It looks like I unintentionally switched things. We want to make it possible for programmers to think of Decimal objects as mathematical values (certainly for comparisons). It looks I accidentally swapped compare with totalCompare. I mistakenly thought that totalCompare was the operation that compares mathematical values, whereas compare compares arbitrary digit strings. I was wrong about that.

I'm happy to drop the more complicated comparison. But I'm not 100% on that. There may be some use cases where one needs to compare Decimals as digit strings, not mathematical values. Perhaps @sffc might know of a use case coming from the Intl world?

[littledan]

Let's err on the minimal side, and take this operation out. We can consider re-adding it later if someone comes along and presents a strong argument for it.

[sffc]

I would support doing something similar to what we did in Temporal where .equals is full equality and .compare is fuzzy equality (ignoring time zone and calendar in Temporal). For Decimal that could mean .equals compares full Decimal128 and .compare compares mathematical values.

tc39/proposal-temporal#625

[jessealama]

The current status is that we'll have a Temporal-style compare operation that accepts arbitrary decimals, never throws, and whose range is { -1, 0, 1, NaN } (because of NaN polluting things). The compare method will work with both the cohort and the quantum, allowing us to distinguish e.g. 1.2 from 1.20.

Apart from that, we'll have <, =, ≠, ≤, >, and ≥ which work with the (extended) mathematical value of their arguments.