tc39 / proposal-decimal

Built-in exact decimal numbers for JavaScript
http://tc39.es/proposal-decimal/
497 stars 18 forks source link

Use "cohort of" and "quantum of" rather than array indices #156

Closed jessealama closed 5 months ago

jessealama commented 5 months ago

Also, restructure definitions of "is zero" and "is finite" for Decimal128 values.

Partial fix for #155

jessealama commented 5 months ago

(This is just an editorial change.)

jessealama commented 5 months ago

To do this, I think we need to have a definition of "the quantum of d" in the introduction. It's currently not there. We also have some inconsistency between "the cohort of d" and "cohort(d)" there.

Agreed. One difficulty though is that "cohort(d)" is understood by ecmarkup as an invocation of an AO. Currently, "cohort(d)" is just defined in prose. It could be an AO, though.

ptomato commented 5 months ago

You could define it the same way as e.g. floor(x) is defined in ecma262 (see the section "Mathematical Operations")

jessealama commented 5 months ago

You could define it the same way as e.g. floor(x) is defined in ecma262 (see the section "Mathematical Operations")

That's a great idea. I've done that now for both cohort and quantum.

waldemarhorwat commented 5 months ago

This looks good, but as an end goal we should work towards v being alwyas a real number rather than sometimes a decimal and sometimes a real.

In some cases, such as an input to RoundDecimal128, then yes, v should always be a real number.

In other cases, such as the definition of the «v, q» tuple, we have v be a member of the set FiniteDecimalCohorts. Here v is either a nonzero real number or one of two special spec symbols which we happen to write as +0𝔻, -0𝔻.

v is never a Decimal128 value. The 𝔻 suffix just distinguishes these symbols from +0𝔽 and -0𝔽.

In my initial design (prior to the one I published as issue #122) I had v always be a real number, but that caused too much confusion. Due to the need to distinguish ±0, the representation of a Decimal128 became «svq», where the sign s ∈ {-1, 1}, nonnegative magnitude v ∈ {n × 10q | nq ∈ ℤ, 0 ≤ n < 1034, -6176 ≤ q ≤ 6111}, and q is as before. One problem became the constant need to strip the sign when writing these tuples and add it back when reading them. To get the mathematical value one can't just use v; one needs to multiply it by s.

The major problem with that approach was that we need the cohort function throughout the spec but we can't define one that returns a real number for zero — that would coalesce +0 and -0 and produce incorrect results.

The math algorithms already must include special cases for +0 and -0, so the current definition of the «v, q» tuple is much simpler.

ptomato commented 5 months ago

It might prevent confusion about whether +0𝔻, -0𝔻 are Decimal values, if we were to write them as spec enums: ~positive-zero~, ~negative-zero~.