fractionDigits and significantDigits

Current Behavior

The current design is incoherent in its interpretation and usage of fractionDigits and significantDigits, especially in the places where it computes those from provided values. Some examples:

The computed significantDigits is never used in the spec and has no effect on the output. The computed fractionDigits specifies the number of digits to output after the decimal point, which sometimes results in incorrect output, as seen in the table above.

Corrected Behavior

I propose that we adopt the mathematical definition of fractionDigits to be the power of 10 of the least significant precise digit of the value. This works for both zero and nonzero values:

Negative fractionDigits are required if we want to faithfully store the precision of numbers in exponential notation. Thus, if we include exponential notation as part of the resolution of issue #52, then we must allow and process negative fractionDigits.

significantDigits

Since it's never used, I propose that significantDigits not be computed.

On the other hand, the explainer provides a method to read significantDigits of Amounts. That method is not in the spec, and I assume the spec is correct here. If we wish to introduce such a method, we should define significantDigits in terms of fractionDigits as follows:

If $value$ is finite and nonzero, let $e$ be the unique integer for which $10^{e}\le\lvert value\rvert\lt 10^{e+1}$. Then let $significantDigits = e + fractionDigits + 1$. This results in the following for the above examples:

Unfortunately significantDigits becomes degenerate if $value$ is zero. For this reason my preference is to not compute it and not provide an accessor to read it. If provided as an option, we should ignore it if the input is zero.

Infinities and NaN

fractionDigits and significantDigits have no effect on infinities and NaN, so we should ignore them if provided as options on input.