You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The measure proposal allows JS programmers to represent numbers with a dimension (unit). It adds new capabilities to JS by exposing CLDR unit data.
As currently envisioned, a measure object contains
an underlying number value (e.g. a JS Number)
a unit
a precision
Example: new Measure(1.3, "gram", 2) is intended to be a datum that corresponds to 1.3 grams, with a precision of 1/102 (i.e., the true mathematical value is in the interval [1.29, 1.31]).
(Invocations of the measure API should be understood as suggestions to stimulate discussion; as of writing, measure has only recently reached stage 1 and its experimental API is very much subject to change.)
As it stands, measure is a nice companion to decimal. Fixing the unit (and especially if the unit is undefined or explicitly dimensionless), and allowing the other two parameters to vary, we have a space of measure instances that fairly closely tracks what IEEE 754 Decimal is intended to capture, namely a decimal number (understood as a mathematical value) plus a quantum.
IEEE 754 defines rules of arithmetic and other mathematical operations, and specifies, in particular, the quanta of the results of mathematical operations from the quanta of the operations arguments. As it stands, measure does not really support arithmetic on the underlying numeric values; measure's notion of arithmetic is focused on units (e.g. convering "meter" and 2 to "meter squared").
Given the conceptual overlap between measure and what we have called non-normalized, or full Decimal128, some questions arise:
Should the measure proposal be included, at least in part, in the decimal proposal?
Does measure give us all, or enough, of what we want out of full Decimal128?
The text was updated successfully, but these errors were encountered:
I see measure and decimal as distinct proposals. To my eyes, measure aligns more closely with 402, though I am also open to the idea there may well be a minimal, core part of measure that could be part of 262 to which decimal could refer (see below). The explicit references to CLDR and the demand that 262 implementations need not support CLDR reinforces this line of thinking.
Measure can proceed independently of decimal. I could see a v1 of measure that supports JS Numbers (and maybe BigInts, too?) going live, regardless of the status of decimal. Decimal v1 could then build on measure v1. I can see measure supporting Decimal128 values (whether we opt for normalized or non-normalized, or both) for the underlying numeric value. Likewise, I can see that we could construct a Decimal out of a measure, provided the measure's unit is missing or explicitly dimensionless (throwing in all other cases).
Distinct proposals imo, as long as the oath remains open to have a Messure that contains a decimal primitive that’s just as ergonomic as one containing a number primitive.
The measure proposal allows JS programmers to represent numbers with a dimension (unit). It adds new capabilities to JS by exposing CLDR unit data.
As currently envisioned, a measure object contains
Example:
new Measure(1.3, "gram", 2)
is intended to be a datum that corresponds to 1.3 grams, with a precision of 1/102 (i.e., the true mathematical value is in the interval [1.29, 1.31]).(Invocations of the measure API should be understood as suggestions to stimulate discussion; as of writing, measure has only recently reached stage 1 and its experimental API is very much subject to change.)
As it stands, measure is a nice companion to decimal. Fixing the unit (and especially if the unit is undefined or explicitly dimensionless), and allowing the other two parameters to vary, we have a space of measure instances that fairly closely tracks what IEEE 754 Decimal is intended to capture, namely a decimal number (understood as a mathematical value) plus a quantum.
IEEE 754 defines rules of arithmetic and other mathematical operations, and specifies, in particular, the quanta of the results of mathematical operations from the quanta of the operations arguments. As it stands, measure does not really support arithmetic on the underlying numeric values; measure's notion of arithmetic is focused on units (e.g. convering
"meter"
and2
to"meter squared"
).Given the conceptual overlap between measure and what we have called non-normalized, or full Decimal128, some questions arise:
The text was updated successfully, but these errors were encountered: