fractionDigits and significantDigits

[waldemarhorwat]

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:

Input value	computed fractionDigits	computed significantDigits	Output value
120	0	3	"120"
"1.20e2"	2	3	"120.00"
"1.410e15"	3	4	"1410000000000000.000"
"0.05"	2	3	"0.05"
".05"	2	2	"0.05"
"5e-2"	0	1	"0"
0	0	1	"0"
"000.00"	2	5	"0.00"
"0.00"	2	3	"0.00"
".00"	2	2	"0.00"
"00e-2"	0	2	"0"

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:

Input value	mathematical fractionDigits
0	0
"0.0000"	4
".0000"	4
"0e-3"	3
"1245.000"	3
120	0
"120.0"	1
"00120"	0
"0.05"	2
".05"	2
"5e-2"	2
"5.0e-2"	3
"1.23e3"	-1
"1.410e15"	-12

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:

Input value	computed fractionDigits	computed significantDigits
0	0	degenerate
"0.0000"	4	degenerate
".0000"	4	degenerate
"0e-3"	3	degenerate
"1245.000"	3	7
120	0	3
"120.0"	1	4
"00120"	0	3
"0.05"	2	1
".05"	2	1
"5e-2"	2	1
"5.0e-2"	3	2
"1.23e3"	-1	3
"1.410e15"	-12	4

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.

[jessealama]

This ought to be taken care of by our use of proposal-intl-keep-trailing-zeros's SDO for computing significant digits. cc @eemeli

[waldemarhorwat]

The fractionDigits and significantDigits computations are still broken in the same way. Current behavior is unchanged from the "Current Behavior" table in my July 30 comment above. Run through the examples in the table to see what goes wrong.

Right now I can't even tell what the intended behavior is supposed to be due to a todo in the description of rounding.

As I mentioned above, significantDigits is problematic enough that I don't think we should compute or store it.

±∞ and NaN still throw. They shouldn't, per the resolution of the other issues.

[jessealama]

I was puzzled to see this because we have taken a look at these issues, so I took a look, and it looks like when we changed the build setup for generating the spec text, we ended up working with an old build. The spec text is up-to-date but the corresponding HTML wasn't. Sorry for the confusion. Can you please take another look?

[waldemarhorwat]

The new spec code accepts ±∞ but crashes (produces a spec algorithm step impossible to execute) on NaN. It also crashes on 0 and -0. The fractionDigits and significantDigits computations are still broken in the new code in roughly the same way as before — try the faulty examples in the table above. It's still hard for me to tell what the intent of those is, as they are used inconsistently.

[eemeli]

As I mentioned above, significantDigits is problematic enough that I don't think we should compute or store it.

I've been thinking about this as well recently, and I don't think without further information we can know whether '4200' has two or four significant digits, or whether '0.042' and '4.2e-2' have the same or different numbers of significant digits.

Note that this uncertainty does not apply to computing the fraction digits, which we can and should always relate to the digits in the mathematical value, i.e. make it so that new Amount('4.20e-2').fractionDigits === 4.

In other words, I agree that we should not compute significant digits if they're not explicitly given by the user.

I do, however, think that we should store and provide an accessor for significant digits when they are given, to account for cases likenew Amount(1234, { significantDigits: 2 }) where a single fractionDigits would need to take the negative value -2 to accurately represent the value's precision. Rather than allowing for that, we can and should use both fractionDigits (=0) and significantDigits (=2) to communicate the precision. As in:

let a = new Amount(1234, { significantDigits: 2 })
[a.fractionDigits, a.significantDigits] // [0, 2]

let b = new Amount(1234)
[b.fractionDigits, b.significantDigits] // [0, undefined]

let c = new Amount(1234, { fractionDigits: 2 })
[c.fractionDigits, c.significangDigits] // [2, undefined]

This would also match the behaviour of Intl.NumberFormat's default rounding priority.

[waldemarhorwat]

The significantDigits concept is unsound for the dual of the case of new Amount(1234, { significantDigits: 2 }), where the value is a fraction. It's natural for fractionDigits to be negative; this must happen with exponential notation. See the examples I gave in the original post.

Another issue with significantDigits I just discovered in the new spec is that merely providing significantDigits as input breaks the computation of fractionDigits. For example, new Amount("0.00") produces fractionDigits of 2. However, new Amount("0.00", {significantDigits: 3}) produces fractionDigits of 0, resulting in the output "0".

[eemeli]

It's natural for fractionDigits to be negative; this must happen with exponential notation. See the examples I gave in the original post. See the examples I gave in the original post.

I do not agree that it's natural for fractionDigits to be negative. Yes, there is a logical meaning that we can assign to such values, but we shouldn't do that. The value represented by "1.23e3" has no fraction digits, and therefore its fractionDigits value should be 0, rather than -1.

[nicolo-ribaudo]

I agree with everything that Waldemar wrote. We've been talking for ages about how:

1. fractional digits and significant digits are two sides of the same coin, and you can easily compute one from the other (which we mentioned multiple times in reply to Mark's questions about their relationship).
2. we care about trailing zeroes, so 1.23e5 and 1.2300e5 have different significant digits, and thus they have different fractional digits (because of the above).

Given (1) it's not the end of the world if we only have one of the two, although it'd be nice to not have to compute the other manually.

I think it'd be fine to have .significantDigits even if sometimes it degenerates. In that case we could choose either:

• 0, which is what we also pick for NaN and infinities.
• -Infinity, which is what you get by rewriting Waldemar's formula above to $significantDigits = 1 + fractionDigits + \lceil log_{10}( value ) \rceil$.

[jessealama]

This is me just thinking aloud here, but the way I interpret the proposed notion of fraction digits is that it is an index into the sequence of the string of decimal digits of the mathematical value. Negative indices mean we chop off digits from the end. Thus, with "1.23e3" we have "1230" as the mathematical value but we consider "123" to be significant (because the fraction digits, in this setting, is -1). Whereas with "1.230e3" we also have "1230" as the mathematical value but consider "1230" as significant (because the fraction digits is 0, hence we take the whole string).

[eemeli]

Is there any prior art for interfaces in other libraries that may display a fraction digit count as negative, or that allow setting a negative fraction digit count? Either in JS or any other language, for formatting or other number manipulation purposes?