(This is just an editorial change.)

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.

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

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.

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 «s, v, q», where the sign s ∈ {-1, 1}, nonnegative magnitude v ∈ {n × 10^q | n, q ∈ ℤ, 0 ≤ n < 10³⁴, -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.

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