May review

[waldemarhorwat]

Here's my review so far. I like the direction and approach. A number of problems remain with rounding which will make users believe that Amount can't be used to get reliably rounded results. Also, parts of the spec contradict itself and the explainer, and I'm not sure what the intent there is.

• My main observation from last meeting still stands: whatever behavior we standardize in the first released version should be the behavior we're happy with long-term, including for things like converting 2m to person-height in the US or France. We shouldn't make users set a flag in the future to get the good result rather than the one we standardized first. Releasing this simultaneously with Intl-Sequence-Units is one possible solution.
• The explainer and spec contradict each other in the convertTo API. The explainer has unit and usage options, the spec does not.
• The spec's note in the Amount constructor is incorrect: The spec always stores Number and BigInt arguments directly in [[AmountValue]], regardless of the rounding options.
• Exponents of 0 are not preserved when handing a string such as "0e-4". I'm happy with that behavior (and wouldn't want to change it) but wanted to make sure that's clear to everyone.
• Rounding continues to produce surprises:
  • Converting 5 grams to tonnes results in 0.0000049999999999999996 tonnes instead of 0.000005 tonnes. This is caused by double rounding when doing the conversion. There are techniques to do the conversion with just a single rounding at the end which would produce the exactly rounded result as long as the conversion factors aren't too large (i.e. we're not converting solar-masses to daltons).
  • Converting "0.15" meters to meters with conversion options fractionDigits=1 and the default rounding mode "halfEven" produces "1e-1" meters, which is incorrect. The correct answer is "2e-1" meters. Again, multiple rounding is the culprit here.

[eemeli]

The explainer and spec contradict each other in the convertTo API. The explainer has unit and usage options, the spec does not.

Presuming that you mean locale and usage, you're right; I filed #109 for this.

Converting 5 grams to tonnes results in 0.0000049999999999999996 tonnes instead of 0.000005 tonnes. This is caused by double rounding when doing the conversion. There are techniques to do the conversion with just a single rounding at the end which would produce the exactly rounded result as long as the conversion factors aren't too large (i.e. we're not converting solar-masses to daltons).

Could you clarify what techniques you're referring to here? And would you agree that iterating on this would be appropriate to do within Stage 2?

I find it interesting that these operations don't produce the same results:

5 * 1e-6 === 0.0000049999999999999996
5 / 1e+6 === 0.000005

Converting "0.15" meters to meters with conversion options fractionDigits=1 and the default rounding mode "halfEven" produces "1e-1" meters, which is incorrect. The correct answer is "2e-1" meters. Again, multiple rounding is the culprit here.

So would this be the behaviour with the following code, or something else?

let a = new Amount('0.15', { unit: 'meter' });
let b = a.convertTo({ unit: 'meter', fractionDigits: 1, roundingMode: 'halfEven' });

With the above, my understanding is that in convertTo we end up with a convertedValue of 𝔽(0.15), formatted as '0.2', and eventually b.value set to '2e-1' as expected.

[eemeli]

The spec's note in the Amount constructor is incorrect: The spec always stores Number and BigInt arguments directly in [[AmountValue]], regardless of the rounding options.

This is a bug, fixed in #111.

[sffc]

5 * 1e-6 === 0.0000049999999999999996

The "problem" here is not the fact that this particular binary operation produces this result, it's that the result is being stringified without applying Intl formatting rules, which restrict the number of fraction/significant digits.

[waldemarhorwat]

The explainer and spec contradict each other in the convertTo API. The explainer has unit and usage options, the spec does not.

Presuming that you mean locale and usage, you're right; I filed #109 for this.

You're right; I meant locale and usage.

Converting 5 grams to tonnes results in 0.0000049999999999999996 tonnes instead of 0.000005 tonnes. This is caused by double rounding when doing the conversion. There are techniques to do the conversion with just a single rounding at the end which would produce the exactly rounded result as long as the conversion factors aren't too large (i.e. we're not converting solar-masses to daltons).

Could you clarify what techniques you're referring to here? And would you agree that iterating on this would be appropriate to do within Stage 2?

There are techniques to compute $𝔽(ℝ(f)\times \frac{i}{j})$ where $f$ is a Double and $i$ and $j$ are integers with only one rounding step.

I find it interesting that these operations don't produce the same results:

5 * 1e-6 === 0.0000049999999999999996
5 / 1e+6 === 0.000005

That's due to multiple rounding. 𝔽(1e-6) ≠ 1/𝔽(1e+6). The latter is exact, the former is already rounded, so you get two rounding steps in computing 5 * 1e-6.

Converting "0.15" meters to meters with conversion options fractionDigits=1 and the default rounding mode "halfEven" produces "1e-1" meters, which is incorrect. The correct answer is "2e-1" meters. Again, multiple rounding is the culprit here.

So would this be the behaviour with the following code, or something else?

let a = new Amount('0.15', { unit: 'meter' });
let b = a.convertTo({ unit: 'meter', fractionDigits: 1, roundingMode: 'halfEven' });

Yes, this code will produce an Amount with the incorrect value "1e-1".

With the above, my understanding is that in convertTo we end up with a convertedValue of 𝔽(0.15), formatted as '0.2', and eventually b.value set to '2e-1' as expected.

No, formatted becomes '0.1' due to multiple rounding.

[eemeli]

With the above, my understanding is that in convertTo we end up with a convertedValue of 𝔽(0.15), formatted as '0.2', and eventually b.value set to '2e-1' as expected.

No, formatted becomes '0.1' due to multiple rounding.

I still don't see where that happens. We're calling the same AO in Intl.NumberFormat atm, and demonstrably

new Intl.NumberFormat('en', { maximumFractionDigits: 1 }).format('0.15')

gives '0.2' as its result. Is there something we're doing subtly differently in this proposal?

[waldemarhorwat]

With the above, my understanding is that in convertTo we end up with a convertedValue of 𝔽(0.15), formatted as '0.2', and eventually b.value set to '2e-1' as expected.

No, formatted becomes '0.1' due to multiple rounding.

I still don't see where that happens.

It happens because of multiple rounding: Amount.prototype.convertTo coerces the string to a Number whose mathematical value is 0.1499999999999999944488848768742172978818416595458984375 (the first rounding). That's passed to FormatNumericToString which rounds it to one fraction digit, breaking ties to even, producing "0.1" (the second rounding).

We're calling the same AO in Intl.NumberFormat atm, and demonstrably

new Intl.NumberFormat('en', { maximumFractionDigits: 1 }).format('0.15')

gives '0.2' as its result. Is there something we're doing subtly differently in this proposal?

The way it's written, I can't figure out what Intl.NumberFormat.format does. I read the spec of Intl.NumberFormat.prototype.format, but can't make sense of what it actually calls due to too much indirection.

[sffc]

Intl.NumberFormat rounding works on mathematical values, not floats, and is defined here:

https://tc39.es/ecma402/#sec-torawfixed

[eemeli]

It happens because of multiple rounding: Amount.prototype.convertTo coerces the string to a Number whose mathematical value is 0.1499999999999999944488848768742172978818416595458984375 (the first rounding). That's passed to FormatNumericToString which rounds it to one fraction digit, breaking ties to even, producing "0.1" (the second rounding).

Ah, found the bug, and filed #112 to fix it. I think @jessealama when writing this and me when reading it were presuming (incorrectly) that determining the MV of a Number would always work the same way it's done in ToIntlMathematicalValue.

[jessealama]

Ah, found the bug, and filed #112 to fix it. I think @jessealama when writing this and me when reading it were presuming (incorrectly) that determining the MV of a Number would always work the same way it's done in ToIntlMathematicalValue.

Indeed, that was the tacit assumption. Thanks for finding and fixing this.

[waldemarhorwat]

The same bug exists in the Amount constructor, introduced there by #111. It should be fixed there too.

[jessealama]

The same bug exists in the Amount constructor, introduced there by #111. It should be fixed there too.

Thanks! I've got a fix for the constructor in #114 .