2025-05-06 [04:18:18.0534] If we do have a call this week, I would like to present a new proposal, which I intend to also present to TG2 for approval to present to TG1 at the upcoming meeting: https://github.com/eemeli/proposal-intl-keep-trailing-zeros The very short description of the proposal is to make it so that this happens: const nf = new Intl.NumberFormat("en"); nf.format("1.0") === "1.0"; const pr = new Intl.PluralRules("en"); pr.select("1.0") === "other"; This is a follow-up to discussions at the last tc39-numerics call. [04:20:34.0953] I would also welcome co-champions for the proposal. [04:32:41.0756] I'd love to talk about it. It seems like this week the numerics call is right before the TG2 one, maybe we can coalesce them? [04:55:42.0592] The TG2 agenda looks pretty full this week. My preference would be to aim for a max 45 min numerics call at its planned timeslot, and to talk about this separately at both meetings as the audiences and viewpoints are distinct. [05:08:28.0938] sgtm [10:16:42.0298] I don't feel "proposal-intl-keep-trailing-zeros" is particularly controversial on its own. It's basically a bugfix. 2025-05-08 [05:39:19.0734] call in 3.5 hours! [06:45:53.0157] At least for me, neither the browser or Android versions of Element appear to support markdown links in the topic, so they're showing up as syntax. [06:46:23.0854] But with the `https://` parts thankfully linkified. [07:52:39.0919] oh, sorry about that -- it works for me [07:52:49.0334] I can unmarkdown things [09:02:22.0375] Meeting time! [09:53:05.0649] ICU4X meeting conflict today, sorry. I'll be in the TG2 meeting though! 2025-05-12 [03:47:15.0568] Possibly interesting/relevant from a "tc39-numerics" PoV, I happened to notice that jschoi has submitted https://github.com/tc39/proposal-bigint-math/ for Stage 2 advancement at the upcoming meeting. [04:06:27.0189] absolutely, I've been following this privately but we can definitely talk about these ideas together [04:06:29.0315] thanks! [08:44:20.0642] > <@jesse:igalia.com> absolutely, I've been following this privately but we can definitely talk about these ideas together If you or eemeli have any feedback, concerns, or coordination regarding BigInt Math and its interaction with other numerics proposals, let me know. I’ll be making my presentations soon. [09:04:49.0907] jschoi: https://github.com/tc39/proposal-bigint-math/issues/27 2025-05-16 [15:57:46.0367] When are people getting to A CoruΓ±a? We should have a numerics mini summit 2025-05-17 [02:45:51.0804] I'm arriving rather late on Tuesday night, but staying on for the Web Engines Hackfest. 2025-05-19 [23:32:53.0352] I'll be there on the 27th! [04:12:24.0624] Ok, maybe those of us who are there on Tuesday can get dinner, and then there should be enough time later in the week and weekend to pull others in 2025-05-20 [00:38:21.0620] and in anticipation of that, we have the biweekly JS numerics call this Thursday! 2025-05-22 [05:42:30.0060] it looks like I have some unexpected childcare duty today; I'm afraid I can't meet with y'all as planned [05:42:45.0640] you're welcome to meet; if you do, please do add any interesting items here [05:43:14.0868] a number of us will be in A CoruΓ±a next week, so I'm looking forward to working with y'all face-to-face soon 2025-05-28 [00:49:12.0559] numerics fans! Shall we do a minisummit while we're here? One idea would be to meet tomorrow after plenary [00:49:32.0457] AFAIK a number of us are also here next week for the Web Engines Hackfest [01:13:23.0967] eemeli Time to get the fractionalDigits vs fractionDigits bikeshedding on the agenda! [01:14:17.0067] There isn't much extra time this week, but I want us to reserve a nice chunk of time for this. I would be open to a nice Saturday walk to Fisterra with JS Numerics on the agenda. [01:15:55.0576] The community event is tomorrow an hour after the meeting ends, and AFAIK ryzokuken and I are due to talk about MF2 there. [01:16:33.0521] yep the community event starts 18:30 tomorrow [01:16:48.0341] Friday could also work? at the moment Friday seems to be kind of empty [01:17:28.0711] I already have Friday booked for time with the Igalia Intl team about Intl Era Month Code, etc. [01:18:56.0724] Could do a numerics dinner tomorrow after the community event? [01:35:28.0865] that might be getting a bit late but I'm open to it [01:41:48.0646] I'd prefer during the day on Saturday than after a long day of meetings and community event [01:42:32.0116] It seems the TC39 schedule is light on Friday so maybe we could reach out to the chairs to reserve a block for a breakout session on this [01:44:08.0800] I'll float the idea to the chairs; there may be some interest in breakout sessions as we did in Seattle [01:48:16.0121] I'd be fine with anything on Friday. Not really up for scheduling work stuff for Saturday; I'm rather looking forward to having some time off. [01:55:16.0007] Are y'all going on the city tour today? (I went on it last time I was here) [02:01:09.0516] I leaning towards not doing it (I've also already done a tour) [02:01:42.0898] (but I'll be at the dinner) [02:28:29.0807] I will [02:29:05.0136] both options sound good to me and slightly preferable than doing it after the community event [02:33:25.0159] Getting a timeslot within the schedule on Friday sounds like the best outcome. [02:35:57.0496] PR set up: https://github.com/tc39/agendas/pull/1891 [02:40:22.0517] I added a slides link PR for keep-trailing-zeros, with content copied almost verbatim from its readme: https://docs.google.com/presentation/d/1gunNRRXJNdDwqTHh-XjV3ueI8PFasRI9WcF4KfWvxE0/edit?usp=sharing [02:43:51.0403] Maybe add an example showing that the proposed behaviour is the same as when you force the `.0` through minFractionalDigits [02:50:21.0045] Do you know if there is any language where PluralRules differs between `1.1` and `1.10`? [02:51:29.0025] Done, I think -- added slide 6. [02:56:31.0987] Apparently these: - Bosnian (bs) - Lower Sorbian (dsb) - Croatian (hr) - Upper Sorbian (hsb) - Latvian (lv) - Macedonian (mk) - Prussian (prg) - Serbian (Latin) (sh) - Serbian (sr) [02:57:34.0625] but these differences would be respected in the language-specific plural rules, right? [02:58:47.0734] Yes. [02:58:50.0483] iow it would already be buggy, today, and buggy perhaps right after launching this change, but fixable later [03:02:50.0297] My npm package `make-plural` already handles string inputs in the way that's being proposed, hence being able to generate the above list with: ``` import plurals from 'make-plural' Object.entries(plurals).filter(([lc, fn]) => fn('1.1') !== fn('1.10')) ``` [07:43:15.0466] ok we presented our case again [07:43:30.0214] congrats on getting preserve-trailling-zeroes to stage 1 [07:43:31.0133] ! [07:44:24.0903] it seems that there's some non-trivial interest in having a polymorphic amount [07:45:39.0642] one thing that I'd like to see are arguments for that, different from the (reasonable, understandable, valid) desire to have a numeric notion that can handle all "numerics" [07:45:58.0394] * one thing that I'd like to see are arguments for that, different from the (reasonable, understandable, valid) desire to have a notion of amount that can handle all "numerics" [07:46:45.0438] I thought that we walked back from the idea of supporting bigints (at least, bigints with more than 34 significant digits) [07:47:09.0761] IIRC the main motivation for that was cryptocurrency [07:47:38.0564] That's not the conclusion I drew [07:48:20.0218] the motivation for me is "if it's not tied to one single numeric type, it should handle them all" [07:49:22.0712] I'd be interested to know how much slower a polymorphic amount would be compared to a decimal-backed amount [07:49:43.0894] * the motivation for me is "if it's not tied to one single numeric type, it should handle them all" (to be clear, decimal-only is fine, number-only is fine, but if it's decimal and number i'm going to insist it also include bigint) [07:49:54.0484] I mean, surely it's not *faster*, and I can see, without digging into any details, why it would be slower [07:50:15.0033] we also generally don't position decimal as something fast [07:52:03.0086] (I always hesitate to emphasize this becuase I don't want to be misunderstood as being totally insensitive to performance) [07:53:00.0863] Is performance being proposed as a rationalisation for Amount? I thought that it explicitly was _not_ for Decimal as a whole. [07:53:35.0650] Polymorphic Amount is probably not _that much_ slower, but my point is that it's not _free_, and I haven't heard motivation for why we would otherwise prefer Polymorphic Amount over Decimal Amount [07:54:11.0364] right, performance isn't being proposed in connection with amount [07:54:40.0868] An Amount supporting all numeric types would not need to be fully polymorphic, like the polyfill it could hold one BigInt and one Number to represent all numeric values. [07:55:02.0467] (bigint for the value, number for the count of fractional digits) [07:55:47.0398] ah, a kind of bigdecimal amount? [07:55:53.0004] And then it could have separate `toNumber`, `toDecimal`, and `toBigInt` methods. Which could throw. [07:55:54.0745] Yeah. [07:57:53.0174] In particular considering non-intl use cases, I think supporting the numeric values that we already have in JS with Amount kinda counts. [07:58:01.0818] I was in the middle of drafting a message saying that Decimal Amount avoids problems exactly like this [07:58:51.0486] It doesn't really "avoid" the problem, just moves it to happen in the constructor. 2025-05-29 [00:59:31.0104] the decimal continuatin will be this afternoon (early, not late) [01:42:19.0998] here are the continuation topics: [01:48:30.0349] not sure what WH has in mind with pi to 72 significant digits; this isn't one of the (many, many) Number values that are exactly representable in base-10 having > 34 significant digits [01:48:52.0281] * not sure what WH has in mind with pi to 72 significant digits; this isn't one of the (many, many) Number values that are exactly representable in base-2 and having > 34 significant (decimal) digits [01:49:41.0798] I'd love to hear more about use cases for `equals` for amounts [01:50:13.0235] it got removed not because of any opposition to it, just ignorance of any concrete need [01:50:40.0745] (I added it in the latest version of the Decimal polyfil, fwiw) [01:52:41.0046] It confounds me how any value type wouldn't have an equals function. As the most basic use case, I would like the ability to store these in a hash set. [01:52:42.0986] MM's question at the top ("Why is amount tied to decimal?") might have been answered by N-ic's email [01:53:15.0557] but it might also be another form of "why a monomorphic decimal-backed amount instead of a polymorphic one" [01:53:17.0836] I still have to answer again to Mark [01:53:54.0318] sgtm -- that's convincing enough [01:54:48.0835] for the exponential notation question, I'm not sure if there's any issue. All the examples we listed use decimal digit strings but we intend to support exponential notation, too [01:55:02.0457] The Equals function gets a bit more fraught with Polymorphic Amount (are numerically-equal Number, BigInt, and Decimal Amounts .equals to each other?) [01:55:08.0118] right [01:56:06.0075] I think that instead of Polymorphic Amount, I like your idea of String Amount. Many of the Polymorphic Amount problems go away. [01:56:26.0872] So the question should be Decimal Amount or String Amount. [01:56:51.0935] a String-backed amount definitely aligns with the main use cases for amount [01:57:23.0266] conversion function (`toDecimal` etc.) might throw but maybe that's not so bad [01:57:56.0450] * conversion functions (`toDecimal`, `toBigInt`, `toNumber` etc.) might throw but maybe that's not so bad [01:58:02.0065] We can discuss that in an issue but I feel like `toDecimal` could have an options argument that tells it whether to round or throw [02:00:30.0971] If we do string amount, I'd prefer conversions to be cast-like operations, e.g. `Decimal(amount)` and `BigInt(amount)` rather than `amount.toDecimal()` and `amount.toBigInt()` [02:04:34.0846] I think E-emli suggested this approach, too? [02:04:57.0652] I would also prefer something like a "string amount". Provided that its `.toString()` was a numeric string, then `new Decimal(amount)`, `BigInt(amount)`, and `Number(amount)` would all work. [02:05:49.0873] a String-backed amount also leaves open the possibility of adding new numeric types [02:05:52.0047] I don't want to get ahead of ourselves on `.toString()`; I want it to be able to hold a unit annotation [02:06:03.0686] Or some other syntax for rationals [02:06:37.0404] `"4/3"` or `"1.50[meter]"` might be valid string outputs [02:06:58.0483] But not as part of the Decimal proposal [02:07:10.0959] We should make it future-proof though [02:08:05.0952] the decimal continuation might happen after this talk (!) [02:09:29.0627] As in, before lunch? [02:09:39.0104] yes [02:09:58.0482] As long as Waldemar and Mark Miller are on the call [02:10:18.0096] WH is here but MM isn't (and he might not be here in the early afternoon, either) [02:10:39.0800] but there are too many contraints for the late afternoon [02:10:45.0115] (that's my understanding from the chairs) [02:10:55.0378] We could do a WH continuation now and a MM continuation later (both shorter and therefore easier to fit in) [02:11:07.0050] neither expressed a constraint fwiw [02:11:20.0930] we have enough constraints explicitly laid out \ [02:11:51.0088] * we have enough constraints explicitly laid out that it feels a bit harder accommodating implicit constraints [02:12:06.0013] Based on the queue, it looks like the WH items are most of what's left [02:17:31.0929] In preparing my slides for the meetup talk this evening, I'm reminded that I still don't recall us getting an answer on whether "redefine BigInt" is feasible [02:18:33.0337] redefine bigint? was that the idea of extending bigint with a new property indicating a decimal point index? [02:19:53.0158] IIRC this was an alternative path towards getting "decimal" as a primitive [02:21:30.0116] Yes. If we did that, then that would also be the Amount type, since it is a superset of the others. [02:22:12.0723] Re "the Amount type", do you mean the type of the numerical value within Amount? [02:22:38.0058] yes [02:22:38.0604] If so, I agree. [02:22:52.0454] * Yes. If we did that, then that would also be the [numeric portion of the] Amount type, since it is a superset of the others. [02:24:14.0651] one question would be the data model -- BigInt is an unlimited data type but Decimal128 has bounds [02:25:11.0377] I guess Decimal128 wouldn't be the way to go [02:25:15.0802] (for this approach) [02:25:19.0708] Yah. [02:26:04.0518] "Modified BigInt" is more like "BigDecimal" which is closer to String than Decimal [02:27:56.0275] thinking about arithmetic on these values, it's a sort of back-door rational number (but restricted to values that have finite decimal representations) [02:28:53.0563] (btw that is definitley doable, and not slow; I'm not raising a performance concern) [02:28:55.0027] Is there any way in which a string-backed Amount could be distinguished from a bigdecimal-backed Amount by a JS user? [02:29:54.0417] (I don't think there is or should be any difference) [02:30:55.0358] to my mind nothing sticks out; they seem basically interchangeable [02:32:15.0403] That's mostly correct, yes, except that it may prevent us from supporting rationals where a string like `"4/3"` could be a thing we support [03:01:03.0604] it seems that we're converging toward a String-backed Amount that would support all "numerics" via cast-like operations suggested by Eemeli and Nic [03:01:58.0571] Note that string amount is not a solution to all problems, as we might need to redefine that for example 1e+1 and 1e1 are the same number but different strings [03:02:18.0989] right we'd need to settle on normalization here too [03:02:51.0569] decimal does that kind of normalization in the sense that it accepts both of those but outputs only the 1st [03:05:28.0936] I can say with extremely high confidence that redefining bigint is not feasible. It is a primitive type with existing well-defined integer-only semantics, e.g. `4n / 3n === 1n`. [03:05:42.0699] No, I would say that we're converging on this being a feasible alternative, not necessarily converging on the preferred approach [03:07:22.0688] Just add a new operator and define `/` as integer division. I see this as a papercut to be weighed with other pros and cons but not a fatal flaw [03:09:30.0704] for storage, it might be a bit odd to have bigints be either an integer or a decimal [03:09:50.0326] even if we could smooth out the ergonomics and surface area [03:10:11.0839] bigints already require a heap, so I don't think it's much cost [03:10:49.0515] In other words, they are _already_ not particularly efficient in their storage. We're making a slightly-inefficient-and-not-widely-used type into a slightly-more-inefficient-but-more-widely-used type [03:15:37.0770] oh, "just" add a new operator? And it's not only that anyway, there's also existing ecosystem use of bigint for alignment with interoperable data models such as Syrup and CBOR, in which arbitrarily-sized integers constitute a distinct type from arbitrary decimal and/or binary fractions [03:17:25.0138] Yes, the data model concerns are something worth discussing, the nature of the issues involved there [03:17:51.0555] to be clear: not only do I have high confidence that redefining bigint is not feasible, but furthermore I am personally inclined to oppose any such attempt [04:43:35.0173] Jesse (πŸ‡ͺπŸ‡Έ): Should we steer the conversation to one of the questions we need answers from MM [04:43:47.0085] Better use of time than NaN [05:18:39.0820] I don't really understand the relevance of the rounding discussions, given that AFAIK the only place where rounding might happen with Amount is when going from a high-precision numeric string to Decimal (if that's what's used as its internal representation). Any Amount-internal fraction/significant digit rounding will presumably happen with respect to the value's internal representation, so all of it will happen consistently. [05:20:27.0318] yes, I also didn't quite detect the substantive issue that we were trying to get at in the rounding discussion [05:20:40.0180] surely, such things would be a stage 2 concern [05:22:12.0490] even Intl, with its huge limits, surely has to handle rounding, when given massive digit strings [05:22:42.0674] I do think that unless we use something like a numeric strings as the internal representation, then a constructor needs to be able to define the rounding mode. Would the currently-proposed `.from` static method allow for a second argument setting that? [05:23:09.0896] we could add a 2nd argument [05:23:37.0107] Do any of the prior-art Temporal `.from` methods allow for a second argument? [05:24:26.0030] IIRC those are all single-argument methods [05:25:01.0192] this reminds me of the discussion of whether we should also have a constructor, not just `.from` [05:25:24.0626] the constructor would be like Temporal's, where every argument is needed [05:25:37.0430] to totally specify everything, without fallbacks [05:50:39.0672] I would think that the Intl.NumberFormat model of value+options bag matches much better, esp. considering future extension for unit/currency support. [05:54:34.0418] procedurally, how should we think about presenting a String-backed Amount? would it continue to be part of the decimal proposal? [05:59:30.0375] I would think that'd be easier done as a separate refactored proposal-measure. [05:59:40.0272] (not saying we've totally switched to that approach; at this point, it's an interesting potential alternative. just asking hypothetically) [06:02:22.0365] otoh in our current discussions of (Decimal.)Amount, we've had the luxury of not yet worrying about units, the thinking being that Measure will round out the picture [06:03:00.0378] iow even a String-based Amount could make sense in the Decimal proposal, because it is indeed a kind of numeric value [06:03:09.0805] and it works [06:03:24.0690] it's like part 1 of a 2-part movie [06:04:16.0689] it does make sense on its own [06:04:29.0524] A minimal non-Decimal Amount could start out with `unit` and `currency` as string-valued optional properties, and include special handling in Intl.NumberFormat when an Amount used is used in a `.format()` call. [06:04:56.0709] ah, interesting, good point -- I like the idea of pointing to those bits of Intl as prior art [06:06:26.0467] As we're proposing a single class for handling both currency and unit formatting, we're going to have the potential for `.format(amount)` throwing no matter what, so gating the supported units at that point rather than in the Amount constructor also makes sense. [06:06:57.0527] And doesn't introduce a dependency in ECMA-262 on the ECMA-402 list of supported units. [07:04:24.0632] Procedurally, I wonder if we could get Stage 2 on Decimal and Decimal.Amount, followed by the proposal to extend Decimal.Amount to support dimensions and higher prevision [07:04:46.0526] (in which case we would rename it from Decimal.Amount to something else, perhaps in a Numerics namespace) [07:06:25.0986] this sounds like a reasonable path -- I think the committee understands decimal and decimal.amount fairly well at this point. the motivation for increased limits comes more naturally from a discussion of measurements [07:06:50.0610] * Procedurally, I wonder if we could get Stage 2 on Decimal and Decimal.Amount, followed by the proposal to extend Decimal.Amount to support dimensions and higher precision [07:10:00.0570] Or we could just leave out Decimal.Amount from the Decimal proposal, and introduce Amount separately under the measure proposal. [07:10:36.0634] My long-standing position is that I don't support the Decimal proposal without the i18n solution [07:11:35.0034] Would those concerns be potentially resolved if we were to propose a non-Decimal Amount for Stage 2 before proposing Decimal for Stage 2? [07:11:49.0743] I could be reasonably happy with String Amount to Stage 2 and Decimal to Stage 2 later [07:12:23.0854] That sounds like a thing that could be done relatively easily from where we are now. [07:13:16.0022] except for the fact that we haven't presented String Amount to committee before and don't have a temperature check on it :) [07:13:40.0393] if so then I wonder if we need to pivot to measure amount for now [07:15:41.0926] I think the most vocal objections to Decimal.Amount as currently proposed have been from Mark and me, regarding the value limits that Decimal imposes. A string-based Amount would resolve those concerns, so I could well believe it getting through unless wholly new concerns are raised. [07:16:04.0111] And as I discovered with Intl.MessageFormat, asking for Stage 2 might be the only way to surface those. [07:16:19.0017] I think it makes *some* sense to do a String-based amount in decimal (called Amount, not Decimal.Amount) [07:16:51.0012] (I think it should be `Numerics.Amount` and `Numerics.Decimal` but that can be resolved pre-2.7) [07:17:51.0644] it makes sense because the use cases for decimal, especially the i18n ones, need (Numerics.)Amount [07:18:25.0624] I would prefer bare `Amount` over `Numerics.Amount`, but I agree that this should not be a stage 2 blocker. [07:19:04.0746] To calrify, I don't dislike `Numerics.Amount`, but prefer the non-namespaced one. [07:19:09.0462] * To clarify, I don't dislike `Numerics.Amount`, but prefer the non-namespaced one. [07:20:54.0321] It's not dissimilar to `SeededPRNG` being better as `Random.Seeded` but probably only if there are other things in the `Random` namespace [07:22:52.0211] imo we've made lots of mistakes by *not* optimistically namespacing things [07:23:07.0504] eventually everything gets something else related to it added [07:29:51.0762] On a separate note, have we considered/discussed whether `Amount.p.valueOf()` should explicitly throw like `Decimal.p.valueOf()` does? For the latter I gather it's primarily done to prevent something like `d1 + d2` from appearing to work, but I'm not sure that the argument made for Decimal wholly applies to Amount. The ergonomics cost of casts like `BigInt(amount)` and `Number(amount)` not working is kinda high. [07:30:50.0385] my initial gut reaction would be for valueOf to return a serialized number [07:30:57.0249] (without units/currency) [07:31:13.0217] we should do what Temporal does, which I is to throw on valueOf [07:31:13.0617] That would work for me, certainly. [07:31:27.0491] * we should do what Temporal does, which is to throw on valueOf [07:31:32.0397] (my response was to Jesse's suggestion) [07:31:57.0096] I'm not in favor of valueOf or toString returning something that is equal if the corresponding Amounts are not equal [07:31:58.0040] Why does Temporal's behaviour here matter for Amount? [07:32:33.0860] ah, I meant not exactly the number but the number + precision [07:32:39.0681] digit string iow [07:32:58.0628] this should satisfy the constraint you have in mind sffc [07:33:53.0250] how important are casts in comparison to explicit method calls? [07:34:02.0532] Temporal decided to throw on valueOf for a number of well-motivated reasons, which I think also apply here. If valueOf returns a string, then people _are_ going to take amt1 + amt2 and get garbage [07:34:04.0543] Number(amount) vs. amount.toNumber() [07:39:25.0818] I'm inclined to make valueOf throw, to avoid mixing, following the logic of decimal [07:40:33.0340] (I wonder if this thinking was one of the "stop casting things" series of talks by KG?) [07:42:32.0294] sorry "stop coercing things" [07:47:13.0820] btw I realize this is getting into the weeds but what should we do about (1) NaN, (2) -0, and (3) +/infinity? [07:47:30.0475] one argument is that we should support all of them because decimal does, and so does intl [07:48:06.0086] another approach would be to ban them, the thinking being that an "amount" is always a *finite* amount [07:48:32.0309] -0 is a finite amount [07:48:41.0983] true [07:48:43.0575] banning nan and infinity tho seems fine to me, as long as it throws for them [07:49:06.0607] should we normalize -0 to 0? [07:49:28.0038] i strongly dislike doing that (as i'll be talking about in the clamp continuation) [07:49:34.0353] but, tbf, that's probably what most people will want done [07:49:39.0672] yeah [07:49:58.0835] * i strongly dislike doing that overall (as i'll be talking about in the clamp continuation) [07:50:03.0623] I'd like us to have `Amount(0).equals(Amount(-0))` to be `true` [07:50:11.0803] at a minimum [07:50:41.0132] i also dislike that but i think it's much more defensible given === and the concept of an amount [07:50:47.0072] ah ok interesting [07:51:12.0995] like, in general i think IEEE's -0 behavior is confusing and bad and we shouldn't constrain ourselves to something whose importance and impact we've long since surpassed [07:51:27.0331] but waldemar for sure, and others possibly, would not be happy with deviating from ieee 754 [07:51:33.0376] right [07:54:40.0305] the same line of thinking -- "don't deviate from IEEE 754" -- could also be an argument for supporting NaN and infinity [07:55:12.0401] well, supporting a subset isn't necessarily "deviation" [07:55:33.0164] we do have things like `Infinity.toPrecision(5)` --> `"Infinity"` [07:55:39.0326] (rather than throwing) [07:55:49.0849] I think ensuring that the Amount value was guaranteed to be finite would be a good idea. [07:55:55.0928] sure but that's from the olden days when coercing was the thing [07:56:08.0469] the *golden* olden days [07:56:09.0406] having to account for the special Infinity and NaN strings is gross [07:56:14.0741] agree [07:56:39.0477] ok it sounds like we have consensus on supporting finite values only, as well as -0 [07:57:19.0063] For the interoperability story, an Amount that was able to represent any finite value would be probably the most valuable approach. [07:58:17.0949] I think `-0` should absolutely work as an input value, but normalising it to `0` has precedent in `String(-0) === '0'`. [07:58:57.0994] sgtm [07:59:08.0309] seems like a stage 2 concern to me [10:08:25.0592] Is it already the case that for two Number-s `x` and `y`, that `x === y` implies `String(x) === String(y)` ? [10:28:05.0919] Yes. [10:29:30.0618] That would align with my expectation, and it's also the case for Temporal types, and it's a large part of why I would like to have that property for Amount, too. [10:29:50.0059] (including an Amount containing units.) [10:33:28.0175] Equality of amounts implying equality of their string representations is quite straightforward, but _inequality_ of amounts implying inequality of string representations is not quite so straightforward. [14:40:10.0349] yes, but note that `===` returns true for distinct values `0` and `-0`, so that implication only holds because [Number::toString](https://tc39.es/ecma262/multipage/ecmascript-data-types-and-values.html#sec-numeric-types-number-tostring) _also_ treats those values the same (`2. If _x_ is either *+0*𝔽 or *-0*𝔽, return *"0"*.`) 2025-05-30 [01:06:24.0155] agreed, though I think in our case we ought to have that guarantee because we track precision [01:14:44.0859] That works fine for number+precision, but what happens when we include units and currencies in the Amount? `<42, EUR>` and `<42, USD>` should not compare as equal, but if their `toString()` values are different to ensure that, how can a user easily get at the `'42'` string value? For a toy example like this that can be available via e.g. `.toDecimal().toString()`, but that breaks for values beyond 34 digits. [01:15:17.0957] the latter part seems expected tho [01:15:32.0773] Which "latter part"? [01:15:38.0641] if you can't make a numeric and then get the string you want, then it seems like you just can't get that string? [01:15:58.0082] phrased another way, if decimal can't stringify properly after 34 digits that's a problem to fix in decimal, not amount [01:16:43.0000] For context, I'm thinking here of a non-Decimal Amount, i.e. one that can support numerical string values beyond Decimal. [01:17:11.0858] ah [01:17:22.0807] As in, values in the numeric string range supported by Intl.NumberFormat. [01:17:41.0548] (Anything up the Math.MAX_VALUE, with up to 100 fraction digits) [01:17:49.0257] * (Anything up to the Math.MAX\_VALUE, with up to 100 fraction digits) [01:18:10.0324] ah [01:19:29.0581] `.toString` can have an options bag similar to Temporal `.toString` functions [01:20:35.0646] `.withUnit(null).toString()` would work, too. But not `.toDecimal().toString()` as it loses precision. [01:21:36.0559] I had not noticed the Temporal toString options bags, that would certainly work for me. [01:23:19.0168] do we want to expose any limits coming from Decimal128 Γ  la Math.MAX_VALUE? [01:27:55.0944] I think not, because that would unnecessarily limit support of all bigint values. [01:28:25.0626] * (Anything up to Number.MAX\_VALUE, with up to 100 fraction digits) [01:28:48.0150] (corrected my comment above to refer to Number.MAX_VALUE, which is what I meant) [01:30:47.0623] maybe this is a question for the decimal proposal in the narrow sense, not related to amount/measure [01:51:08.0205] one of the tasks for the minisummit is to iterate on the README [01:51:19.0304] I've made some changes and will push them to GitHub [01:51:24.0823] we can work there [01:53:02.0158] https://github.com/tc39/proposal-decimal/pull/195 [03:36:31.0237] thanks everyone for chipping in [03:37:05.0214] I'm glad that we dug in to the string-backed amount idea [03:38:31.0161] I think there's still some uncertainty about that [03:38:52.0851] My research question going into that was "are there delegates hesitant about String-based Amount who are onboard with Decimal-based Amount" and I think the answer to that is, yes [03:39:04.0320] right