Use Intl mathematical values in ConvertUnitValue

[jessealama]

Related to #115 , use (Intl) mathematical values in ConvertUnitValue to remove at least one step of rounding. Before:

Return _value_ × 𝔽(_sourceFactor_ / _targetFactor_)

Now:

Return 𝔽(ℝ(_value_) × _sourceFactor_ / _targetFactor_):

[github-actions]

PR Preview Action v1.8.1
🚀 View preview at https://tc39.github.io/proposal-amount/pr-preview/pr-125/
Built to branch gh-pages at 2026-10-02 02:53 UTC. Preview will be ready when the GitHub Pages deployment is complete.

[gibson042]

I thought there was too much resistance to mathematical-value multiplication and division, but am happy if that's not the case.

[sffc]

With #115, not all results become exact; for example, 0.3𝔽 * 3 still equals 0.8999999999999999𝔽. I think the way to specify this is to use Math.fma.

EDIT: This example is describing what the behavior should be, which is not what this PR specifies.

[gibson042]

With #115, not all results become exact; for example, 0.3𝔽 * 3 still equals 0.8999999999999999𝔽. I think the way to specify this is to use Math.fma.

Where in the changes of this PR do you see any step that could result in that calculation?

[sffc]

With #115, not all results become exact; for example, 0.3𝔽 * 3 still equals 0.8999999999999999𝔽. I think the way to specify this is to use Math.fma.

Where in the changes of this PR do you see any step that could result in that calculation?

This PR appears to do all math in MV space, including converting a float to an Intl MV, which treats the float as the shortest decimal, not the full-precision floating point MV. However, that cannot be implemented without decimal arithmetic, which is a hard no from engines. The approach in #115 is a compromise that gets us closer to exact arithmetic by removing the double-rounding in a * b / c but still allowing it to be done using floats.

[eemeli]

This seems like quite a surprising change, and would require explicit implementer approval before we apply it. Introducing a requirement for an implementation to be able to do decimal multiplication is... a lot. And rather like with Math.fma(), it's a capability that, if approved, should not only be available in this one corner of the spec.

So if you would like us to do this, I think you need to first present a separate proposal introducing that capability to the language, and then we use it here.

[jessealama]

The thinking behind these changes was to imagine a world where we had Math.fma so the Number-based calculations offered by Amount would be, effectively, as good as it gets. The idea is that moving (more of) the calculations to mathematical values, as done here, captures that intent without actually using Math.fma in the spec text. But it sounds like what I'm up to here is going beyond what Math.fma can offer. At a minimum, an argument needs to be made for that proposition. I'll keep this PR open but mark it as a draft, for now, and will tackle the rounding issues in a separate PR using Math.fma. If that PR looks good, we can close this one.

[sffc]

But it sounds like what I'm up to here is going beyond what Math.fma can offer.

Right. We can't require implementors to do more than Math.fma can offer.

[sffc]

Let me qualify that comment: The objective of FMA is to avoid multi-rounding of floats. It might be possible to specify that behavior without using Math.fma, so long as it is done carefully.

See some of my more recent comments in #115.