Where to apply Level of Measurement?

[keilw]

Either in Unit or Quantity the new LevelOfMeasurement attribute should be applied for arithmetic decision making.

Needs #130

[keilw]

@unitsofmeasurement/experts, @unitsofmeasurement/contributors Based on discussions and some code snippets (e.g. by @desruisseaux back in June) from #95 I take, that Unit would be the best place for a LevelOfMeasurement attribute / method like getLevel()?

[desruisseaux]

I think it should rather be in Quantity. I'm not sure that conversion from "interval °C" to "ratio °C" make sense for example (i.e. I do not have any use case in mind where we would want to convert from Units.CELSIUS to Units.CELSIUS_INTERVAL). Instead, the use cases that I see are conversions that preserve the level of measurement of the quantity. For example:

• If we have an interval of 2 K that we want to convert to degrees Celsius, the result is an interval of 2°C.
• If we have a value of 2 K on the ratio scale that we want to convert to degrees Kelvin, the result is a value of -271.15°C on "ratio" scale ("ratio" may not be the right word in this case…).

We want Quantity.to(Units.CELSIUS) to preserve automatically the level of measurement of the quantity. We do not want to force user to check the Quantity unit in order to determine if (s)he should specify Units.CELSIUS or Units.CELSIUS_INTERVAL in argument to the to method.

Level of measurement of a Quantity are not changed by unit conversions, but by arithmetic operations applied between two quantities. For example "ratio" - "ratio" = "interval".

[keilw]

Well "describes the nature of information within the values assigned to variables." from the Wikipedia article sounds slightly in that direction. The question then is, where does it have to be set that is least intrusive? On the Unit a natural place would have been when defining e.g. CELSIUS, but if there's a valid use case for having -271.15°C as RATIO and the same as INTERVAL, if that is the case, we may have to find a different place but we could not do it without assuming a default level when none is provided. Or can it always be derived through operations?

This example from June 15 was under the assumption, it was more beneficial on the Unit:

Quantity add(Quantity that) {
    Unit u1 = this.getUnit();
    Unit u2 = that.getUnit();
    Unit uc = u1.level(u2.getLevel());    // We will convert in unit of u1, but taking in account the nature of u2 (quantity or increment).
    UnitConverter c = u2.getConverterTo(uc);
    newValue = this.getValue() + c.convert(that.getValue());

    // The result is in unit of u1, but is it an absolute value or an increment?
    // Note: following code could be factorized in a convenience method.
    boolean isIncrement1 = u1.getLevel() == LevelOfMeasurement.INTERVAL;
    boolean isIncrement2 = u2.getLevel() == LevelOfMeasurement.INTERVAL;
    boolean isResultAnIncrement = u1 & u2;
    Unit uf = u1.level(isResultAnIncrement ? LevelOfMeasurement.INTERVAL
                                           : LevelOfMeasurement.RATIO);

    return new Quantity(newValue, uf);
}

I only changed the enum name, otherwise it is like the one from June. So even with pseudocode, where is a level set? The Wikipedia description of the different levels also says "Most measurement in the physical sciences and engineering is done on ratio scales. ", therefore it would be a hassle and not acceptable having to do something like Quantities.getQuantity(10, KILOGRAM, RATIO) every time, if that was a place where it had to be explicitly set.

https://en.wikipedia.org/wiki/Level_of_measurement#Ratio_scale states, "The Kelvin temperature scale is a ratio scale because it has a unique, non-arbitrary zero point called absolute zero." So Quantities.getQuantity(10, KELVIN, INTERVAL) seems to make no sense.
Or are you saying 10 K - 1 K or 100 m - 5 m automatically turns their level into INTERVAL?

https://www.isi.edu/~ulf/amr/lib/popup/quantity-types.html

[desruisseaux]

The idea was that 10 K - 1 K automatically turns their level into INTERVAL. But I need more though; on one side it is true that an ORDINAL level of measurement for example applies better to Unit than Quantity. But for the particular case that we were trying to solve in #95 (i.e. the result of 1°C + 2°C), having the information associated to Quantity instead than Unit allow more convenient conversions as described in my previous comment. I need to think more about that…

[keilw]

Ok, we could also do a vote, probably running a bit longer than the one for the name of a new type, but it should not take quite as long as #95 itself ;-)

[desruisseaux]

To me, vote should start only after we are done analyzing the problem, listing the choices and debated pros and cons…

[keilw]

I would have hoped much of this was done in #95 but no problem doing it in this ticket although it was meant as an action item. I changed it to a question. @unitsofmeasurement/experts, @unitsofmeasurement/contributors or @unitsofmeasurement/observers please (at least after the busy conference week) share your thoughts and preferences whether the Unit or Quantity should be used to apply the new LevelOfMeasurement attribute, or something else like UnitConverter, although literature mostly points to either the unit or quantity (sometimes in a slightly different context also called Measure or Measurement) This is a good overview: http://www.indiana.edu/~educy520/sec5982/week_3/measurement_rsm.pdf
Here is another source: https://math.tutorvista.com/statistics/scales-of-measurement.html