- Shane Carr - Google i18n (SFC), Co-Moderator
- Ben Allen - Igalia (BAN)
- Yusuke Suzuki - Apple (YSZ)
- Louis-Aimé de Fouquières - Invited Expert (LAF)
- Jesse Alama - Igalia (JMN)
- Nicolo (NRO)
- Eemeli Aro - Mozilla (EAO)
- Richard Gibson - OpenJS Foundation (RGN)
- Frank Yung-Fong Tang - Google i18n, V8 (FYT)
- Discussion Board
- Status Wiki -- please update!
- Abbreviations
- MDN Tracking
- Meeting Calendar
- Matrix
BAN: We've merged some editorial things since last meeting. Anba abstracted locale base name, which generally improves readability and clarity on what "language tag" should mean. I have several PRs open which I'd appreciate reviewed when people get a chance.
A tech preview update is landing in CLDR 46. We're trying to establish a syntax that is basically final. For instance, .match is an operation on variables, now. One other change is relaxing the stability policy: No promise that a 2.0 parser will be able to parse 1.2 syntax. Previously we had complicated reserved blocks in the syntax for later expansion use; what we’ve ended up opting for instead is getting rid of the reserved content and not promise that a 2.0 parser can consume 1.2 syntax. This allows for later 2.1, 2.2, 2.n syntax changes with more possibilities than what we’ve had previously.
Budgetary pressure to get MessageFormat v2 out this calendar year, which may be a faster timetable than we want in this group.
SFC: Timeline for a 2.0 release this year not realistic.
EAO: I agree with this sentiment. We are getting direction from the chair of the CLDR TC that we should get a 2.0 out this calendar year. Reaching out to Mark Davis may be useful.
SFC: We should nevertheless keep moving on the user study. I saw they had a meeting yesterday that wasn’t at a time I could attend, but I don’t know what conclusions they made.
EAO: Next steps from there are Michael [?], EAO, and Addison Phillips working out details, timeline may not align with completion before 2.0 release needs to be locked. This would be a part of CLDR 46.1.
SFC: I think that if there are things in the user study that can be addressed via non-syntax (what formatters are available, etc), that’s fine. If there are concerns that could effect 2.0 changes, that could be hard to reflect. It could be that the user study comes back and says the syntax is kind of fine, or good enough for our use case, and that’s the type of signal we need to bring back to TG1. if that’s the outcome, it’s a good outcome. Non-web people using the syntax could be motivation to get this into ECMA-402. User studies should still keep moving; I think there’s definitely still room.
EAO: There is more scope for corrections to be made due to stability policy relaxations.
SFC: Mark Davis seemed surprised about the study when I talked with him last week, and I was surprised by the timeline.
https://github.com/tc39/ecma402/wiki/Proposal-and-PR-Progress-Tracking
FYT: Intl.LocaleInfo is going to be added to v8 in 130, which is about a week from now.
YSZ: The writing of the spec is done, so not something like the new spec is not implemented. But for Intl.Locale new methods, and Intl.DurationFormat, we’re aligning to what test262 is testing right now.
EAO: A bunch of stuff as usual advancing there, most of it concerning Web standards rather than JavaScript standards, HJS and I have mentioned coming up with a better English to use internationally, rather than American English, particularly with respect to measures. We’re not really ready to present that as a formal thing yet, but it has some decent positive responses. The reason I’m going to need to jump out in about a half an hour is to go talk with the Web Extensions CG to present a demo of what it would look like using MessageFormat2 as an improved syntax for browser addon localization, which is currently available but using custom syntax for just that.
SFC: That’s exciting; getting MessageFormat into these Web-oriented standards is an exciting direction.
EAO: It would be of interest. Call for more overlap in participation, but the i18n working group spends most of their time considering the whole scope of W3C internationalization, most of which isn’t of interest to this TC.
https://github.com/tc39/ecma402/projects/2
NRO: Why are we working on this? A recurring topic when JMN has discussed while talking about Decimal is the usefulness of Decimal for Intl, particularly if it were possible for Decimals to keep track of their own precision. This enables the same value to be passed into multiple Intl objects such as Intl.NumberFormat and Intl.PluralRules and retain the correct behavior. Our hope for the Decimal proposal is to introduce for now Decimal objects, but then in a future proposal make them primitives. In this case, 1 and 1.0 would be equal to each other – no distinction based on precision.
NRO: So we’re exploring removing tracking of precision from Decimal, since it’s not needed in most use cases. So we thought to remove precision from Decimal itself, and then have an object that holds a Decimal number (or a float) together with its precision. I’m asking here because they’re nicely packed together, one thing to pass around, and the various Intl objects could take them, see that this is a number together with its precision, and format it as so.
[ see example ]
NRO: We’re planning on this not having an Intl API. In general we’re looking for feedback, any ideas you may have.
JMN: To add one more point, NRO mentioned that it is currently a stage 0 thing, we will not ask for stage 1, but we will announce the existence of the stage 0 proposal.
NRO: Even though our plan isn’t to advance, we would ask for stage 1 if the group agrees this proposal is good?
EAO: This seems quite interesting; the problem statement and rationale sounds a lot like the rationale of why you'd want the currency code or unit to follow the number input around. It seems like we should have just 1 solution instead of 2 solutions.
Going on from there, with that sort of an approach something like a constructor rather than methods on Number and Decimal as the way of getting one of these might make more sense. I like this, but the scope should be a little bit more than what you’ve got.
FYT: It seems like your proposal is not improving mathematic operations about calculating precision; it's just a data structure?
NRO: Yeah, that's right, since there are multiple ways you might want to propagate precision.
FYT: But eventually you want some code to do that. I wonder why that's not in scope.
NRO: One idea was to basically have this thing be a protocol. Ways you want to propagate precision might be confidence intervals, etc. The thing we suggested was have a protocol such that anything that consumes these objects can implement propagation in userland, and whoever was responsible for formatting it could ask for [?]
FYT: Would a person care about the precision? There are two different kind of user: one that doesn’t care about precision, one that doesn’t. The one who cares about precision will have a stronger need to propagate precision. Most people don't want to figure out how to propagate precision with sine and cosine.
NRO: Even just propagating precision is often not enough. In most examples in Decimal where people cared about precision, they still needed to provide the precision they wanted instead of using the one that gets automatically propagated. If you’re in scientific contexts, you want a different precision than in accounting contexts. So you would still end up having your own implementation, still having to make sure you understand how precision gets propagated
EAO: I see utility for this which doesn't provide the arithmetic methods. I find much more utility in a thing where it is explicitly left to the user to provide that information, if it is to be provided. I would probably find significant digits more universally useful than fractional digits for this.
SFC: Thank you for bringing this proposal forward. I generally agree with the sentiment that the next topic on the agenda is a new version of the smart units proposal, which is a new way to pair units with values, and it makes sense to build a proposal that leverages both of those at the same time. I do think the idea of a protocol, and this being a recommended way to treat units with precisions, could be useful. One question I struggle with is that if we get to this world where we have a really nice numeric type with all of these features – it supports units, currencies, precisions – that serves a lot of the same use cases that Decimal had originally been proposed to cover. There is no way to specify how much of a particular type of money you have; you can’t use a float, because precision problems, and if you have a BigInt you have to record that the BigInt is recording cents rather than dollars, etc. With this new type we have the ability to represent exactly how many yen you have. That’s not something we could do before. You can actually associate it not just the precision, but the precision, and the unit, that is more expressive than decimal128 ever could be. If we have arithmetic methods, an enum say, of how to propagate precision, having room to do that is something we should plan for. This is going in the direction of a programming language primitive, rather than a number bit primitive. In Decimal the idea was to bring all the features of Decimal128 into 262, everyone will be super happy, now we’re introducing a new primordial with a prototype with properties and methods on it. I’ve been asking JMN and the other Decimal128 champions about numbers on performance of Decimal128 instead of being implemented in userland. If performance isn’t a concern, it seems like having a more flexible way of doing this, with objects and prototypes and such, that might be the way to go. This new proposal we’re describing is almost superior to Decimal128, given the use cases listed in the document. That’s a long statement, but that’s my initial reaction.
FYT: One question I have is, right now for example in 262, you have a math library, and you can say 3 log 2. How can I ask the math library what precision it already propagates within log 2. Currently there are mathematical operations that take two numbers and propagate a precision internally on the value return. If you have this new proposal, would it be necessary to let that already pre-existing operation not only tell you what it propagates, but also the precision it propagates.
JMN: I fear that with things like sine and cosine, things are a bit hopeless. There’s no clear standard precision that gets returned; the spec just says “implementation defined”.
FYT: So you need to return something, it already returned it, it propagated, and we have no idea what the precision is. So if you have this number and get something like 1 cosine 2 from a math library, how can I add a precision? I need to have a way to query the math library about how to do that.
NRO: You could have a math library that returns these objects rather than plain numbers.
FYT: Yes, it has to tell you that, otherwise you have no way of knowing.
EAO: I still don’t think we need to immediately make Math.log2 or Math.sine work with precision. One thing to consider is that if we want to make that work later, we now need to ensure that with precision does not have a toPrimitive that gives you a Number? Right now, I can’t remember how if Math.log2 just casts its inputs into numbers, or? If you could now pass a withNumeric that passes to Math.log2, that makes it harder to [?]
NRO: When I brought this with me, I was thinking that in a lot of places other than numbers it would be nice to not throw with these objects but instead fall back, instead of this case of making it forward-compatible.
FYT: Is there a standard syntax to represent precision in syntax? Let’s say we have this new type, and we want a toString, and you want to parse it. Is there a standard way to convert that thing into a string format that we can pass through? Is that a practice in this industry, or not?
NRO: In the scientific world, it’s very common to have the number, a +- symbol, and the radius of the describes the precision. I don’t know if there’s anything standardized in terms of representing in text in computers. In most cases we want that precision to tell us how many digits are significant, so you’d want to stringify it as 1.234 followed by some number of zeros.
FYT: Let’s say you have the thing, you want to string it to a json object, how do we want to present that in the text, parse-in parse-out, is there a standard way to represent that in text?
EAO: I’m pretty sure we want a single number, possibly an integer, so it can be used primarily for the formatting. If we want it more complicated than that, there’d have to be a positive and negative extent of the range, and the set of cases where that’s useful in the real world is much reduced.
NRO: This is also why we were suggested to make this a symbol-based protocol, so that you can have your userland implementation of precision as complex as you want – asymmetrical intervals, etc. – but then once you pass it into Intl, it will just read the symbol to know how many digits are significant.
FYT: Example: you go to U.S. census, and you have numbers that say 35 million people, precision is 1000. How do you present that as opposed to 35 million, precision 100,000. Fractional is easy, but you may have values where precision is bigger than 1 instead of smaller than 1.
NRO: When precision is a power of 10, say 120, you write it as 12 x 10^1, so you’d write it as 12E1 in exponential notation. 12E1 means “the value is 120, the significant digits are just the 12”
let m1 = new Measure(100, "centimeter");
// Option 1: localeConvert (automatically select an output unit)
let m2 = m.localeConvert("en-US", "person-height");
// Option 2: convert (guarantee a specific output unit)
let m2 = m.convert("foot-and-inch");
console.log(m2.number); // 3.28084
console.log(m2.unit); // "foot-and-inch"
let m3 = m2.splat(); // returns an array of measures
console.log(m3.len); // 2
console.log(m3[0].number); // 3
console.log(m3[0].unit); // foot
console.log(m3[1].number); // 3.3701
console.log(m3[1].unit); // inch
SFC: This proposal has several motivating problems. First, we want to prevent abuse of Intl.NumberFormat for the purpose of unit conversion. Second, we want a way to carry a unit/currency with a number for the purpose of formatting. We now have a third motivation for this proposal, since it could include a precision bit and serve the use case over there. The code above is the data model that seems like it might not make the most sense. I may want to included precision. Create a new object Measure, create with a number and a unit (including mixed units)
Prototype methods on it include localeConvert, that gives the locale and the context (as from units.xml) and you get back the converted unit and measure, an array of units and measures in case of mixed units. Unit conversion library with those features on it. Smart units would be easy to implement on top of this; no longer an incentive to abuse smart unit.
EAO: Some more examples of how this could work:
new Measure(100, { unit: 'cm' })
new Measure(1234.56, { significantDigits: 2 })
new Measure(42, { currency: 'EUR' })
So the second argument could take not only a unit but also other types of things. Regarding localeConvert, that could be left out of the initial proposal and potentially added later.
FYT: From your example, internally there’s a two-step process. First you internally figure out what to convert to, then do the conversion, rather than a two-way process to tell me the person’s height in en-US, what should be the unit. Then just a simple conversion that doesn’t need to know anything about the locale to do the conversion.
SFO: The unit that’s targetted varies based on the magnitude of the number. In en-US people say inches for heights under 2 feet, feet-and-inch for taller. Difficult to design an API to “give me the unit for person-height in en-US”. This design has a smaller surface. Here’s the number, also the locale, then give us the localized conversion.
FYT: What I’m afraid is people not being aware of this, abusing the API assuming whenever passing a value, like 1, and that what they get back will be put at inch, or the only answer. If
FYT: People may assume you only have one – the conversion, for the locale conversion, doesn’t convert to one single unit, it converts to several possible units based on the range. People not knowing that may assume that it’s a one-to-one mapping, put a value like 1 (say 1 cm) and use whatever’s returned as a one-to-one mapping. We may eventually need to return the structure so that people are aware of the right way to get it out. I see a point of abuse usage
BAN: As we were conceptualizing it, the methods on our Measure object, the one to convert from one unit to another, is in 262 and is more flexible. convert() takes a Measure with a unit and returns a Measure with a unit. localeConvert takes a measurement and a locale and produces a measurement for that locale, which is less flexible.
FYT: I'm scared about currency conversion!
BAN: No currency conversion.
SFC: [explores three use cases]. If we can come up with a solution that solves all three problems pretty well, that’s superior to three different solutions. If this means we through an exception when we call convert on a non-measurement value, well, we’d have to throw anyway if the unit string doesn't exist, that’s already going to be a function that won’t always work anyway. Or, we could have three separate protocols for each of the three separate use cases.
BAN: So the Measure class shouldn’t necessarily be parsimonious.
NRO: I think it makes sense to have number-with-significant-digits to be part of this, mostly because otherwise we would have to worry about all the possible ways to combine these objects. We could have a Measurement that holds a number with precision, or the other way around, and this just feels cleaner. When you measure something in the world you do have both the precision and the unit, so I expect that we’d record those. In many implementations reducing the number of objects to put there would be good.
BAN: if we had the Measure class right now, would there still be a use case for number-with-precision?
NRO: Assuming we could have a Measure without a unit, then no.
SFC: The absence of a unit is a unit that CLDR calls “one”. I’ll double-check what the actual identifier is. “Base dimensionless unit”
SFC: I urge NRO and JMN to present this at TG1. I’m talking about this proposal as a way to solve three use cases that I identify: unit conversion for smart units, associating a unit with a number to format in messageformat, a third to pull in the precision stuff. Does this also serve the other use cases listed in the Decimal proposal page? Three use cases listed on the headline of this page: representing human-readable decimal values (money) – that’s covered by this. Second use case data exchange. Well, we haven’t talked about how this interfaces with JSON, do we have to define a new string format, do we have to invent something? That’s an area we should explore. And then the third use case is numerical calculations. I think that FYT said earlier that he would like to see the ability to have mathematical functions that propagate precision, EAO said that he’d like to see that not necessarily in the first proposal, but as something to build to.
NRO: Preview of the answer: when it comes to the exchange, the goal here isn’t to design a system, it’s to integrate extant systems. There are databases, etc. that already represent decimal numbers with the full range given by Decimal128, and [something] to present the full range.
JMN: That’s along the lines of the preview answer I’d give: I think of Decimal as a new kind of numerical entity. It’s not going to be a primitive, at least initially, but it’s something that could at some point become a primitive. Measures are a complex entity, no sort of primitive thing. As NRO hinted there’s the notion of exactness. One of the main motivations of Decimal is wanting an exact representation. As humans using decimal, we wouldn’t get that out of this sort of thing.
SFC: In terms of exactness, this proposal would be able to support exactness. In terms of the other point, I want to be able to represent values with a greater precision than what float64 does. Two things: there’s already two other ways that the language offers to represent numeric values with higher precision than float64. We have BigInt. The problem is that it doesn’t represent fractional values. Potentially the unit value could encode “I’m not representing a value of dollars, I’m representing a value of cents.” that would be fine, and consistent with this mental model. The other way of representing high-precision numbers that we have is Strings, and NumberFormat already does this with mathematical value. A string is a mathematical value which can have higher precision than float64. Our understanding was though that strings shouldn’t necessarily be the canonical way in ECMAScript of representing higher-precision numbers. Two of those give away to represent these higher-precision numbers without necessarily having Decimal128. As others have noted, Decimal128 isn’t full precision either. It can’t represent a Java BigDecimal. So in practical use cases Decimal128 is precise enough, but it’s not strictly that for everything.
FYT: When you describe those things that represent a higher precision, the proposal here is to communicate what the precision you pass through is. Passing a very long string for a long quantity of data, that doesn’t tell us the precision. You could pass in 130 digits where only the first three digits are significant. There’s no way to represent that.
SFC: No, I mean being able to represent values beyond what float64 can present. Things like “the smallest difference between two primitive values of a type.” There could still totally be a use case for a Decimal128 numeric primitive. But maybe it’d be cool if some of these use cases could be solved with this proposal. I’m not going to say this in TG1, but I feel like someone like JHD could say “well, if most of the use cases are solved by this Measure type, why not only do Decimal when we can do it as a primitive”? There’s a case – not mine, but it’s a case – that we shouldn’t have a half-baked Decimal while sitting around waiting for primitive Decimal.
SFC: If you’re open to exploring this direction, you and JMN, that’s a direction I’m also interested in.
tc39/proposal-intl-duration-format#209
SFC: Sosuke has said that we need additional tests. Do you consider the JSC implementation to be complete, or do you want the tests before you can say that?
YSK: It’s kind of at a place where it’s passing the tests.
FYT: Anba has some tests in test262, and there are changes in the spec, waiting to get new test262 tests merged.
FYT: the main one we have a concern with is test262 PR #3988
Wait for editorial changes and the last batch of tests to land. Bring back to TG2 in the October meeting to verify readiness for Stage 4, and then ask TG1 for advancement in the November meeting.
SFC: This PR looks good except I would like to have verification that CLDR does not actually try to match ISO 4217.
TG2 approval, pending SFC's query.
Normative: When formatting currency values, only use data on the number of minor units used to display that currency when using standard notation. #925
SFC: After looking at this, I think this is the right solution. CurrencyDigits should not be used in scientific or engineering notation. It is already not used in compact notation, which resolves undefined fractional digits to rounding priority morePrecision.
RGN: I'll approve the PR.
RGN: Is there a way to cover this with test coverage?
SFC: I think it's fine to write tests with currencies that have well-defined fraction digits.
TG2 approval.
SFC: Maybe it's not right to copy-paste the extensions from one locale to another.
RGN: The extensions are refinements. So it is inappropriate to apply the refinements to a different locale.
BAN: +1
SFC: Any other comments?
Close the issue.