Semantics of undefined unit

[gwhitney]

(I think filing an issue is the proper/expected way to file comments from an interested member of the community. If this should be moved elsewhere please let me know. I am commenting from the perspective of a maintainer of mathjs, a library that has an integrated system for manipulating unit-measured quantities, as well as an extensive library of units.)

The proposal states

Note: ⚠️ All property/method names up for bikeshedding.

unit (String or undefined): The unit of measurement with which number should be understood (with undefined indicating "none supplied")

This does not seem to provide the opportunity for a "scalar" or "unitless" Amount. But if there is some future proposal for arithmetic of units, it will very likely need such Amounts. For example, often quantities in Hz are considered equivalently to be in sec^-1, and so if you multiply such an Amount by say new Amount(5, {unit: 'sec'}) you should get something that is a unitless quantity. But you don't want to just downgrade that result to a Number or Decimal -- for one thing, you would lose the precision information, and for another, it would be helpful to know that an Amount times an Amount is always another Amount. On the other hand, we don't want it to be simply be an amount that indicates it is an Amount "with no unit supplied" -- it is explicitly a purely numeric Amount, with no ambiguity.

Therefore, I would suggest that this proposal would be more "future-proof" if some adjustment along one of the following lines is adopted:

1. If there isn't a known use case for "Amount with unspecified unit", then the semantics of having the unit property undefined could be that this is a pure-numeric Amount. Since I don't understand what one might do with an Amount of "5 somethings," without knowing what that something is, I personally would tend to lean in this direction.

2. If there is, then this proposal could anoint the unit value being the empty string as the indicator that this is a purely-numeric Amount. Since I think the likelihood that such Amounts will be needed is high, it seems beneficial to claim that semantic space now, rather than run the chance of new Amount(7, {unit: ''}) having the potential to come to mean something else through usage or other precedent before a follow-on proposal on unit arithmetic is finalized and adopted.

[ljharb]

Why would you need a unitless amount? isn't that Number/BigInt (and in the future, maybe, Decimal)?

[gwhitney]

Why would you need a unitless amount? isn't that Number/BigInt (and in the future, maybe, Decimal)?

I made two arguments for this proposal above:

1. If you downgrade from Amount to Number/Decimal, you lose the precision information you have been tracking through your computation, but that precision information is meaningful and should be taken into account if you use the result of (say) multiplying Hz by seconds in a further computation with other Amounts.

2. It will be helpful (e.g. for typescript typing and for ease of writing uniform code) if one can rely that an Amount times an Amount is an Amount (just as a Number times a Number is always a Number). That's not possible without unitless Amounts.

To these I will add that I was just trying to add the recommendation from the perspective of years of work with mathjs, which indeed has unitless instances of its analogue of Amount, which are called Unit entities therein. We have generally been very glad to have unitless amounts: it makes the Unit system more complete, logical, and easier to implement and maintain and easier to code with. I do realize these are "soft" arguments.

I will also add a third, conceptual argument:

3. As stated, Amounts are for capturing "real-world" quantities, as opposed to mathematical/Platonic ones. As such, some "real-world" quantities are indeed unitless, such as pH, coefficient of friction, and refractive index, to name a few. For consistency, ability to represent their precision, and for ease of arithmetic once there may be operations on Amounts, these unitless real-world quantities should be represented within the Amount system, not outside of it by the coincidence that they happen to be unitless.

In the end, I am trying to help avoid a pitfall in which I see based on my experience that likely in the future there will be a wish to have a unitless Amount. Since such Amounts are indeed a bit special, it's likely best to have one from the get-go.

[hl662]

I strongly agree with the third argument. I work on a TypeScript library used within the Architecture, Engineering, Construction (AEC), and we frequently have to work with ratios and scales.

These unitless, numerical values come from mathematical operations between two unitized(?) values. For example, Meters per meters, or inches per foot, come from 2 units that measure length, then used to calculate a unitless value: a scale factor, used in drawings and architectural sheet plans.

The AEC industry values precision and accuracy regarding floating point numbers, and I'd love to see if unitless amounts can be factored into this proposal ahead of time.