| 04:49 | <sffc> | There's a lot here since I last posted my reply. I think my position on most of the comments here is well-known. In short, I am in support of a clean immutable data type that supports decimal with precision, possibly with future support for units. All methods operate according to that data model, including equals and to/from string. I've already explained my reasoning in GitHub issues including #175 and #181. I don't see anything in the last 100 Matrix comments that would change my logic. If there are specific questions/suggestions/comments/concerns, let's make GitHub issues. I like Matrix for things like sharing slides and asking quick questions, but I strongly prefer GitHub for matters of substance. |
| 17:50 | <nicolo-ribaudo> | sffc Isn't it 34 significant digits, and not 31? (I'm just reading from wikipedia) |
| 17:51 | <littledan> | presumably we're taking off a few to deal with those edge cases Waldemar is talking about |
| 17:52 | <littledan> | I'm not sure what Waldemar meant about rounding mode -- does he want that to be a property of the Decimal.Amount? |
| 17:52 | <sffc> | thanks |
| 18:26 | <Jesse> | I think what WH meant with rounding was triggered by one of my examples: "converting" 42.56 to "42" or "43" if you impute 2 significant digits to the number |
| 18:26 | <Jesse> | it would be "42" using round-ties-to-even |
| 18:27 | <Jesse> | in the current API, there's no place for speciifying a rounding mode, if needed |
| 18:27 | <Jesse> | by contract, Decimal.prototype.toPrecision does allow for specifying a rounding mode |
| 18:27 | <Jesse> | contrast |
| 18:28 | <Jesse> | we could certainyl support that |
| 18:31 | <Jesse> | yeah it's 34, though the exponent gets a bit tricky when dealing with subnormal numbers (extremely close to zero) |
| 18:31 | <Jesse> | but the 34 significaitn digits is true for those numbers, too |
| 18:33 | <Jesse> | we could add that as an optional argument to togetherWithSignificantDigits, as is the case today with Decimal.prototype.toPRecision |
| 18:33 | <Jesse> | but then, yeah, I guess that would need to be stored in the Decimal.Amount value |
| 18:34 | <Jesse> | and pass that to Intl.NF rounding options |
| 18:39 | <eemeli> | My presumption is that we would want the numerical value 42.56 of new Amount('42.56', { significantDigits: 2 }) to be somehow available. |
| 18:39 | <Jesse> | eem-eli thanks for pointing out to MM that he can solve his number formatting needs, today, even with huge/ultra precise numbers by contructing a digit string and passing that to Intl |
| 18:40 | <Jesse> | ah, interesting - we currently have an accessor for the underlying decimal -- which doesn't change when constructing a Decimal.Something -- so that data is recoverable |
| 18:41 | <eemeli> | Because if it's not available, don't we end up with effectively a black-box Amount, and y'all have pushed back against that quite strongly. |
| 18:45 | <sffc> | Decimal.Amount should do the rounding stuff ahead of time. That's kind-of the point. new Amount('42.56', { significantDigits: 2 }) should take a rounding mode. |
| 18:46 | <Jesse> | my thinking is that we store the original value but present only the (possibly rounded) value |
| 18:47 | <eemeli> | Actually, are there use cases for Decimal.Amount that would not be served equally well by a numeric string? |
| 18:48 | <sffc> | #175 |
| 18:49 | <Jesse> | https://github.com/tc39/proposal-decimal/issues/175 |
| 18:51 | <sffc> | I will try to write up my thoughts on Mark and Waldemar's comments, but tl;dr there seems to be a disconnect between both the facts and the goals of the proposal. |
| 18:53 | <Jesse> | I think we don't need to talk about quanta; I didn't quite understand how that came up, and I when i think about Amount I don't feel the need to reach for the concept of quanta |
| 18:54 | <Jesse> | I mean, maybe as an implementation detail, in some implemenations; but it's not necessary to understand the proposal |
| 18:54 | <sffc> | I mentioned the word in the context of an optimization Decimal.Amount makes possible and didn't mean for the conversation to rathole on that |
| 18:55 | <Jesse> | right I undersood you as referring to a low-level detail; sad that we got sidetracked |
| 18:56 | <eemeli> | So the problem we're working around is that we presume that changing the output of new Intl.NF().format('1.0') would not be web-compatible, yes? Do we have any proof of that? |
| 18:57 | <sffc> | I hope one of these days we can align on the axiom that "significant digits", "fraction digits", and "trailing zeros" are equivalent and interchangeable concepts after being applied to a decimal number |
| 18:58 | <Jesse> | I agree we can convert between those |
| 18:58 | <eemeli> | If we presume that the number of trailing zeros can be negative, yes. |
| 18:59 | <Jesse> | I think that's equivalent to "downgrading" the # of significant digits |
| 19:35 | <eemeli> | sffc: To represent e.g. new Amount('42.56', { significantDigits: 2 }) using trailing zeros without losing precision on the original value, we'd need to say something like trailingZeros: -2. |
| 19:36 | <eemeli> | Same actually goes for fractional digits. |
| 19:36 | <sffc> | In my mental model, that thing should absolutely "lose precision". new Amount('42.56', { significantDigits: 2 }) is identically equivalent to new Amount('43', { significantDigits: 2 }) and new Amount('43') |
| 19:37 | <sffc> | Here's another way of explaining this type. It is the intermediate value during number formatting, something that the language cannot currently represent. It is the value after rounding and precision have been applied, but before the digits are converted to their numbering system specific representation. |
| 19:38 | <sffc> | Maybe framing it that way would also help address Mark's concern about why we have this only on Decimal but not on Number |
| 19:38 | <sffc> | Number.prototype.toDecimalAmount could totally be a thing |
| 19:40 | <sffc> | Calling it "decimal with precision" is maybe misleading. It is a "decimal after precision was applied to it" |
| 19:41 | <eemeli> | Except for how intl. NumberFormat treats its trailing zeros, (42.56).toPrecision(2) already does something really close to that. |
| 19:42 | <eemeli> | Hence my earlier question: Are we really sure that we can't fix Intl.NumberFormat? |
| 19:54 | <sffc> | When I worked on string arguments to Intl.NumberFormat.prototype.format a few years ago, I got pushback about "let's please not set precedent for using strings as an intermediate decimal representation" and I got Stage 3 by promising I wouldn't try to use strings in this way. :) |
| 19:56 | <sffc> | So I'm not opposed to exploring whether we could further improve Intl.NumberFormat.prototype.format(String) in a web-compatible way, but that doesn't alleviate the need to have an actual intermediate type. |
| 20:02 | <eemeli> | I don't think I understand the use case for a separate intermediate type if formatting or selecting on a numeric string accounts for the precision in that string representation. |
| 20:19 | <sffc> | For one, you wouldn't be able to do decimal.withSignificantDigits(5).withUnit("meter") without an upgraded intermediate |