Formatting with increased precision seems like an error case

[jridgewell]

const d = new Amount(1.23456, { significantDigits: 2 });

d.toString() // '1.2'

d.with({ significantDigits: 4 }).toString() // '1.200' or '1.235'?

From today's presentation, we discussed what should happen when formatting with a higher precision that the input's precision. I think we came to an agreement 1.235 is incorrect. But I think even 1.200 is incorrect, it implies a precision which is not captured in our input.

Quoting a bit from wikipedia:

The following types of digits are not considered significant:

• …
• Spurious digits that arise from calculations resulting in a higher precision than the original data or a measurement reported with greater precision than the instrument's resolution. link

As an example, the amount we hvae is the calculation of some operation. Eg, if we had a * b === 1.23456, with a = 2.46912 and b = 2.0. Even though the calculation has a precision precision of 6, the actual amount represented here only contains 2. It is incorrect to ever print this value as 1.23456 because I am only certain of the first 2 digits.

I would accept d.with(4).toString() as 1.2, making it very clear that we cannot create more precision from an amount that doesn't have that to begin with. But 1.200 seems wrong, because we have no idea what those 00 should be.

[jridgewell]

Thinking about this some more, I think the problem isn't the formatting, but the d.with({ significantDigits: 4 }). We know d only has 2 sigfigs, we can't increase it to 4. That should throw.

[eemeli]

@jridgewell Is your concern restricted to just the .with() method, or do you think the following should throw as well?

new Amount('1.2', { significantDigits: 4 })

[waldemarhorwat]

Echoing eemeli's point, there are lots of common valid cases for increasing precision. A simple example is formatting 5 as dollars with two fraction digits, resulting in "5.00". This increases its precision from 1 to 3.

with should behave in the same way as the Amount constructor.

The concept of a stored precision is not really meaningful and depends on context which can vary. The proposal as it currently stands does not use it consistently. I am writing another issue to expound on that.

[jridgewell]

Is your concern restricted to just the .with() method, or do you think the following should throw as well?

That's fine, we can't know how precise the '1.2' is as a string. But we know when it comes from an Amount through .with().

---

Echoing eemeli's point, there are lots of common valid cases for increasing precision. A simple example is formatting 5 as dollars with two fraction digits, resulting in "5.00". This increases its precision from 1 to 3.

I disagree with this. 5 as an input to the constructor has infinite precision. I can reduce it to 3 without uncertainty. But doing from new Amount(5, { sigs: 1 }).with(3) is nonsense, you can't have certainty what value is represented with more than 1 digit.

The concept of a stored precision is not really meaningful and depends on context which can vary.

Then what's the point of this proposal? It seems your use case is to format, but that's NumberFormat's job, not Amount's.

[waldemarhorwat]

The concept of a stored precision is not really meaningful and depends on context which can vary.

Then what's the point of this proposal? It seems your use case is to format, but that's NumberFormat's job, not Amount's.

My point is that the use of precision in the proposal is inconsistent and currently depends on context. See #54.

The problem with making this an error case is that we've just made new Amount(5).with({significantDigits: 3}) also be an error case. The devil is in the details. See #54.

[ljharb]

I think the difference here is that increased precision IS always an error case - all the cited cases (which are very important!) are about digit padding, not extra precision. iow, 5.4 formatted as $5.40 is end-padding to two digits, not increasing the precision. Thoughts?

[waldemarhorwat]

Every Amount value has a corresponding fractionDigits which is used for its display. If you don't specify it as an option, it's computed from the value. The fractionDigits of new Amount(5.4) is 1. Calling .with({fractionDigits: 3}) on it increases it to 3 and I would hope results in the output "5.400" rather than throwing.

[ljharb]

That seems perfectly reasonable to me.

[jessealama]

Every Amount value has a corresponding fractionDigits which is used for its display. If you don't specify it as an option, it's computed from the value. The fractionDigits of new Amount(5.4) is 1. Calling .with({fractionDigits: 3}) on it increases it to 3 and I would hope results in the output "5.400" rather than throwing.

Yes, that's correct.

[jessealama]

Perhaps there should be an option to indeed throw when we attempt to impute additional precision to a mathematical value than it actually has? For instance:

new Amount("1.2", { fractionDigits: 2 }); // ok
new Amount("1.2", { fractionDigits: 2, imputePrecision: false }); // throws

Integers are an interesting case to think about. I suppose we could think of them as having infinite precision (so "imputing precision" is a misnomer, since we're downgrading precision and potentially rounding). It seems valid to me to also think of them as a sequence of significant digits, so maybe imputing significant digits should potentially throw, whereas imputing fraction digits should be safe.

[jessealama]

Perhaps there should be an option to indeed throw when we attempt to impute additional precision to a mathematical value than it actually has? For instance:

new Amount("1.2", { fractionDigits: 2 }); // ok
new Amount("1.2", { fractionDigits: 2, imputePrecision: false }); // throws
Integers are an interesting case to think about. I suppose we could think of them as having infinite precision (so "imputing precision" is a misnomer, since we're downgrading precision and potentially rounding). It seems valid to me to also think of them as a sequence of significant digits, so maybe imputing significant digits should potentially throw, whereas imputing fraction digits should be safe.

@jridgewell What do you think of this suggestion?

[eemeli]

I don't think we need an additional option to effectively say "please check my work". For the cases where that's actually required, it's trivial to implement manually:

let a = new Amount('1.2')
if (a.significantDigits >= 4) return a.with({ significantDigits: 4 })
else ... // handle error

It's perhaps relevant to note here that we already support this in Intl.Numberformat:

new Intl.NumberFormat('en', { minimumSignificantDigits: 4 }).format('1.2') // '1.200'

[jridgewell]

I don't think we need to change the constructor at all. I think the only thing that would change is with() prevent increasing the known precision.

It's perhaps relevant to note here that we already support this in Intl.Numberformat:

I think this is fine for formatting (even if Amount is used in the formatting), but Amount API means to solve "keep track of the precision of measured values".

[eemeli]

I don't think we need to change the constructor at all. I think the only thing that would change is with() prevent increasing the known precision.

That sounds like it would make the following an error, yes?

let a = new Amount(1.2);
let b = a.with({ significantDigits: 4 });

Note that the input value there is a Number, and so the precision of the first amount would become significantDigits: 2. Considering the above an error would make it practically impossible to create workflows where a precision is attached to an Amount after its creation from a Number, given that its precision could be anything.

Also, it would be quite odd for the above to fail, while this would work:

let a = new Amount(1.2);
let b = new Amount(a, { significantDigits: 4 });

[jridgewell]

That sounds like it would make the following an error, yes?
let a = new Amount(1.2);
let b = a.with({ significantDigits: 4 });

Yes. See also #49 (comment).

It also means '1.2' would fail this case. I think that's fine.

Also, it would be quite odd for the above to fail, while this would work:
let a = new Amount(1.2);
let b = new Amount(a, { significantDigits: 4 });

I didn't realize we could construct from an Amount. That should be an error, too.

---

If we don't want these throw, I think we could also allow the imprecision to be preserved:

let a = new Amount(1.2);
assert.equal(a.significantDigits, 2);

let b = a.with({ significantDigits: 4 });
assert.equal(b.significantDigits, 2)