2025-03-04 [22:32:48.0644] we could juggle the meetings times -- how shall we fix the conflict? Would meeting one hour later (10:00 am America/Los_Angeles) work? [01:10:26.0281] > <@jesse:igalia.com> we could juggle the meetings times -- how shall we fix the conflict? Would meeting one hour later (10:00 am America/Los_Angeles) work? No it needs to be one hour earlier but only in March. I can fix it. [01:12:15.0321] Before and after. ⏱️ [01:25:55.0369] that works for me -- how about for the others? [01:34:02.0647] I'll be on PTO for the next call and will miss it in either case. [01:36:01.0987] there's also a chance to discuss 402-specific aspects in the upcoming 402 call on Thursday [02:43:04.0229] FYI, my PTO starts this Thursday, so I'll miss this week's TG2 call as well. 2025-03-10 [08:53:20.0143] any chance of moving this week's JS numerics call to Wednesday (currently Thursday)? I'll be away on Thursday (and Friday) [09:06:46.0248] Ad an alternative we could switch to the other every other week, which would solve a monthly conflict I have with the TG4-scopes meeting :) [09:08:43.0565] I'm happy to do that -- any thoughts from the others? [09:12:59.0465] (sorry, changing topic, but please folks reply to the message above!) Some calls have an agendas/notes doc linked to in the calendar event, such as https://docs.google.com/document/d/1CD5lIBZLl24XBWbQhokqBdt4Zl7wPAcFJKJrgePr9HU/edit?tab=t.0 Could we have something similar? I find it very useful to have a single place where I can check what folks want to talk about in advance [09:14:44.0609] I'll put together something like that, good idea thanks [09:16:32.0947] * An alternative we could switch to the other every other week, which would solve a monthly conflict I have with the TG4-scopes meeting :) [09:41:44.0263] Since we're talking about scheduling:
I also have a conflict about 50% of the time with the current time slot, the ICU4X Working Group, but it isn't evenly spaced. The time for that meeting derives from TC39-TG2 which derives from TC39-TG1 which is not a regular cadence. I do not have a conflict for the next 3 meeting slots.
[09:57:22.0703] if I understand the details correctly, it should be ok if our call were the same time, just one week later? [09:57:46.0497] (and the failure rate of 50% wouldn't increase) [10:21:59.0653] If we switch the meeting to the other week, then I have a conflict for the next 3 meeting slots, and then OK after that for a while 2025-03-11 [00:25:05.0413] it sounds like there's no optimal time for the next call. The options I can see are: 1. Proceed with the meeting as scheduled (with the understanding that I won't be there) 2. Have the call one day earlier, at the same time 3. Have the call one day later (doesn't work for me) 4. Skip this meeting, see you in 2 weeks & 2 days Can you use an emoji to vote on this? There are emojis for numbers. You can vote for multiple options. A vote indicates that you're OK with the choice. [00:59:39.0519] We didn't get around to fully discussing Rationals at the TG2 meeting, so I don't have a lot of updates on that front. I think the main thing for Amount is making a better case that we benefit from a new prototype for it rather than "just a protocol". [01:23:46.0002] On Decimal itself, I should note that we still haven't fully discussed https://github.com/tc39/proposal-decimal/issues/181. Issues like that ought to have champion group consensus before asking for Stage 2. [01:25:26.0833] I feel uncomfortable that there are 62 open issues on the repository. They should be at least triaged into broad categories like "blocks stage 2", "blocks stage 2.7/3", and "nice-to-have for later" [01:29:06.0355] I want to hear a compelling case for "why we can't just have a Math.decimalAdd function" with behavior as described in that issue. I claim that the only _real_ reasons are ergonomics and the ability to represent more than 34 significant digits; in other words, nothing intrinsic about Decimal128. If that's true, fine, but let's be clear about it. And if ergonomics are the motivating factor, then let's make the ergonomics argument for Amount, too. [01:29:39.0150] * I want to hear a compelling case for "why we can't just have a Math.decimalAdd function" with behavior as described in that issue. I claim that the only _real_ reasons are ergonomics and the ability to represent more than 15 significant digits; in other words, nothing intrinsic about Decimal128. If that's true, fine, but let's be clear about it. And if ergonomics are the motivating factor, then let's make the ergonomics argument for Amount, too. [01:30:17.0227] * I want to hear a compelling case for "why we can't just have a Math.decimalAdd function" with behavior as described in that issue. I claim that the only _real_ reasons are ergonomics and the ability to represent more than 15 significant digits; in other words, nothing intrinsic about Decimal128. If that's true, fine, but let's be clear about it. And, assuming ergonomics are the motivating factor, then an ergonomic Amount (with its own prototype) follows naturally. [01:30:36.0285] * I want to hear a compelling case for "why we can't just have a Math.decimalAdd function" with behavior as described in that issue. I claim that the only _real_ reasons are ergonomics and the ability to represent more than 15 significant digits; in other words, nothing intrinsic about Decimal128. If that's true, fine, but let's be clear about it. And, assuming ergonomics are indeed the motivating factor, then an ergonomic Amount (with its own prototype) follows naturally. [10:31:22.0157] ^ I guess what I'm trying to say is that, as champions, we should form consensus on the roadmap to Stage 2, including key issues to resolve and questions to answer. There was a small amount of backchannel discussion here and in Seattle, but we should turn that into action. Triaging issues into milestones is a great first step. 2025-03-12 [04:55:52.0365] tbh I think, at least in the short term, a `Math.decimalAdd` etc. would be *more* ergonomic than the current approach, which would require `new`s and then a final `toString` [04:56:56.0084] looking at a possible future where decimals are a new primitive type (or exist somehow as sugar), then yes, they would be more ergonomic [04:57:46.0106] > <@jesse:igalia.com> tbh I think, at least in the short term, a `Math.decimalAdd` etc. would be *more* ergonomic than the current approach, which would require `new`s and then a final `toString` I think this depends a lot on whether you are just doing one operation, or a series of operations [04:58:03.0460] what I find awkward about the `Math.decimalAdd` etc. approach is that it's all about strings; this feels conceptually off to me. I think of decimals as numbers [04:58:56.0328] right -- and we want to keep calculation in the forefront, not merely conversion to/from strings [04:59:56.0457] I like the idea of triaging the issues [05:00:53.0715] do you really think so? I think it's meaningful to have decimal as a data type, and this discourages errors [05:01:59.0400] I was trying to suggest that both approaches are bulky; and Nic's point about arithmetic is imo a stronger point [05:02:22.0474] OK, so maybe focus on making the arguments in favor of things, rather than ambiguously making such concessions [05:10:40.0099] it seems odd to me to enable decimal arithmetic but not have decimal numbers [05:11:47.0196] iow I see it not just as an ergonomic concern [05:14:23.0730] but just to wrap up this line of thinking, my intention was to say that, in that one example, focusing on ergonomics is misleading [05:16:01.0486] * tbh I think, at least in the short term, a `Math.decimalAdd` etc. would be _more_ ergonomic than the current approach, which would require `new`s and then a final `toString`, but that's misleading because it's a completely different approach [05:16:46.0241] * I think bulkiness isn't really the main thing to focus on here; we want to reduce errors by making a well-typed interface. [05:20:47.0971] indeed, since we expect one main use cae to be doing calculations, I think if we were to pursue the `Math.decimalXYZ` idea developers would quickly see their code size grow. It seems more natural to me to have entities in the language (decimals) that we can directly work with, rather than stuff the semantics of those entities into static methods [09:43:33.0721] `Math.decimalAdd` is an exercise to demonstrate that we don't _need_ IEEE 754 Decimal128 in the data model of the language in order to represent decimals and have decimal-like arithmetic in the language. We _could_ do it with all of our existing utilities. I don't disagree with the points about a new type discouraging errors; I put that in the ergonomics bucket. The reason I wanted us to do this exercise is because I think we need to be much more clear on why we are proposing this specific shape of proposal. It isn't because there aren't other ways to solve the same problem; it is because we believe that a new type system surrounding decimal numbers will help developers write better, more accurate code. 2025-03-13 [20:46:35.0470] Hey, it looks like only 3 people are invited to the champions meeting event (Jesse, Richard, Eemeli). I assume this is a bug. To fix it, I created a Google Group https://groups.google.com/a/chromium.org/g/tc39-numerics and invited it to the event. Please join the Google Group to be added to the meeting. [20:48:12.0458] I went ahead and added Jesse as a group manager. [06:41:28.0884] I don't understand what is left unstated from previous arguments. Nicolo wrote about the issues here in your presentation on the topic. [06:43:11.0373] issues with Math.decimalAdd include: - If you use strings, it's very easy to accidentally cast it to a number, e.g., if you use most (non-+) numeric operators with it. This will "just work" (almost) by giving you a mostly-correct answer in terms of Numbers. - Strings can represent values which are not contained within the IEEE Decimal128 data model; what should happen with that extra information? should operations silently remove it? [06:44:03.0285] it would be helpful if you explained what is insufficient about these arguments. when you say, let's think about it, it sounds like you're asserting that it hasn't been thought about, which is confusing to me. [06:53:43.0295] (I don't really see either of these arguments as about ergonomics) [09:04:37.0543] Not sure about what we decided for today, but I'm available to meet if there is anybody else [09:06:27.0119] Shane and I are in the meeting [09:07:50.0197] I'm waiting to be let in [09:08:16.0070] (the Google meet link—apparently this invite has both that and Jitsi, one of which should be removed) [09:10:15.0320] Ok yeah Google is not working for me, it's waiting for somebody to let me in but I guess you are not getting the notification [09:10:45.0891] And I see that jitsi has the same problem :/ [09:11:23.0290] Try joining the Google group [09:11:46.0820] I tried but somebody needs to approve that too [09:12:25.0339] That I can help with [09:15:19.0781] Huh? Math.decimalAdd has nothing to do with strings [09:18:24.0644] The presentation I gave in February was about Measure/Amount. I haven't given one about "non-Decimal solutions to the Decimal problem statement". [09:25:15.0505] Experimenting with meeting links: meet.google.com/roa-zuci-ixp [09:28:02.0232] Chris de Almeida: Thanks, try again 2025-03-14 [00:04:24.0442] thanks for proceeding yesterday; I couldn't make it [00:04:34.0755] I see some issue triage was done 2025-03-27 [22:41:24.0037] Hi Jesse can you share an agenda for tomorrow's TC39 Numerics call? [22:43:54.0276] Also does anyone still need to be added to the Google Group? I don't see everyone in this channel in the group. https://groups.google.com/a/chromium.org/g/tc39-numerics [23:08:59.0123] Maybe we can discuss this: https://github.com/tc39/proposal-measure/issues/26 [00:14:32.0846] that looks like a great suggestion -- let's talk about that [00:18:22.0589] Chris de Almeida: I tried editing the Google Calendar JS Numerics item but it seems I can't -- could you please add Mikhail, Ujjwal, Jordan, Romulo, Magnus, Dan, and Nicolo? [00:20:50.0375] > <@jesse:igalia.com> Chris de Almeida: I tried editing the Google Calendar JS Numerics item but it seems I can't -- could you please add Mikhail, Ujjwal, Jordan, Romulo, Magnus, Dan, and Nicolo? We solved this last time by adding people to the Google group instead [00:26:27.0511] ah, I see -- digging in to that group, I still see some people missing. I'll try adding them [00:33:23.0329] done [02:30:38.0134] For today's agenda, could we also discuss the details of banning bare decimal objects in Intl formatters? [02:41:41.0233] sounds good -- here we go: https://docs.google.com/document/d/1O2EQC61TIDtkcvDSkhDf4N_R9GioT0foU2tH9HBdMdQ/edit?tab=t.0 [14:03:40.0260] Bah, it looks like I'd failed to get the recurring Numerics call on my calendar, and missed it today; apologies.