How does the LevelOfMeasurement influence Quantity operations?

[keilw]

How should the LevelOfMeasurement be used for Quantity operations like add(), subtract(), multiply() or to() converting it into another Unit?

There are essentially two questions:

• How to apply LevelOfMeasurement?
• Is it sufficient, or do we need another attribute like Absolute/Relative?

Needs #131
Needs #140

[desruisseaux]

I love Steven's "Level Of Measurement" definitions and would be very happy to see them in the API, but unfortunately I think it does not apply to the question we are trying to answer for #95. The essential question is:

• Is 15°C (for example) an interval or a measurement?

We need two values for that. The closest values in LevelOfMeasurement would be INTERVAL and RATIO, but applying RATIO to a measurement in Celsius degrees seems in contradiction with Steven's definition or ratio. Similar problem appears for the difference between two ordinal values.

Consequently I think that we need something different than LevelOfMeasurement in Quantity. It could be another enumeration, or we could define a Quantity subtype named Interval.

[keilw]

https://www.ryerson.ca/~qms102eb/chap01/t1d_lec.pdf is an interesting source on that.
It clearly states (like every other place you may look for measurement levels) that Is 15°C is an INTERVAL, not a RATIO. Except SCALE (which summarizes both INTERVAL and RATIO, so I doubt it would help us with #95) I never saw the term "Measurement" for the level, only for what we call "Quantity" in some cases.

The interesting point raised by https://www.ryerson.ca/~qms102eb/chap01/t1d_lec.pdf is that 1000m in some cases could be an INTERVAL, e.g. "above sea level" or when comparing the heights of two places.
It also states like many other articles comparing those levels, that RATIO is the highest level and allows all relevant operations while e.g. you mustn't multiply or divide an INTERVAL.
https://www.thoughtco.com/levels-of-measurement-in-statistics-3126349 is also a good and recent comparison.
So INTERVAL and RATIO (while I would not remove the others, just e.g. prevent mathematical operations on a Quantity if it has certain levels) look pretty sufficient. If we have one Quantity being INTERVAL and the other a RATIO, then we should define how calculations can be done. Also what happens when you convert e.g. KELVIN to CELSIUS or vice versa.

[desruisseaux]

Indeed, 15°C is never a RATIO in all literature cited so far. Nevertheless we need a way to said that 15°C is a "measurement" (or other word), as opposed to interval, and RATIO does not appear to be the right word for that. That's why I question whether LevelOfMeasurement is the right enumeration for the problem we are trying to solve.

Yes, 1000 meters can be either a RATIO or an INTERVAL, but for this particular unit (as opposed to °C for instance) the distinction does not have practical impact as far as #95 is concerned.

Saying that we can't multiply or divide an INTERVAL is not completely exact. We can not multiply or divide a measurement on an INTERVAL scale (e.g. 15°C) and consider the result as a measurement. But we can multiply or divide an interval on the INTERVAL scale and consider the result as an interval. For example:

• Two time a temperature of 15°C is not 30°C (i.e 30°C is not twice the amount of heat of 15°C).
• Two time a temperature increase of 15°C is an increase of 30°C. The key difference here is that we are talking about increases, not absolute temperature. When talking about increases, dividing or multiplying is okay.

Said in other way:

• If 15°C is an absolute temperature measurement, then we are not allowed to apply multiplication or division on that value. We need to convert to a RATIO scale first, which is Kelvin degrees.
• If 15°C is a temperature increase (not an absolute measurement), then we can apply multiplication or division directly on the value in °C. The result is an interval, not an absolute measurement.

LevelOfMeasurement tells us which operation are allowed on absolute measurements. The fact that °C is an INTERVAL scale means that divisions and multiplications are not allowed on absolute measurements; it does not mean that multiplications and divisions are not allowed on differences between measurements (i.e. on temperature increases).

Maybe the confusion come from the fact that I used the word "interval" for the difference between two absolute measurements. Let use the words "difference" instead for this discussion. The set of operations allowed depends not only on LevelOfMeasurement, but also on whether the quantity is an "absolute measurement" or a "difference". There is the table as I see it:

Level of Measurement	Applied on absolute measurement	Applied on difference
NOMINAL	=	differences not allowed
ORDINAL	= < >	none
INTERVAL	= < > and + - of differences	= < > + - * /
RATIO	= < > + - * /	= < > + - * /

So as you see there is two orthogonal information: the LevelOfMeasurement (the vertical axis in above table) and the kind of quantity (absolute measurement versus difference). This is the combination of those two information that determine the set of operations allowed.

The information that we are missing right now is the absolute measurement versus difference information. My claim is that it is not the same thing than the LevelOfMeasurement, even if closely related.

[keilw]

Where is the exact source for that table?
https://en.wikipedia.org/wiki/Level_of_measurement looks similar but far from the same.

So how should this be maintained to keep it simple and easy to use?
Throw away LevelOfMeasurement and replace it with some kind of "absolute vs. difference" construct?
Or have both, but then what is the benefit?
It may be something like https://en.wikipedia.org/wiki/Absolute_scale so telling Absolute vs. Relative, but combining it with the LevelOfMeasurement would be extremely awkward and hard to understand for the simple everyday need.
If there is no third option here, then a plain isAbsolute() boolean flag might be the best answer compared to yet another enum or trying to squeeze that into LevelOfMeasurement. Plus if there can be combinations, should we even bother keeping LevelOfMeasurement at all?

[desruisseaux]

Source is mathematic… Wikipedia only provides the "Applied on absolute measurement" column (plus other columns relevant to statistics field). The "Applied on difference" column is not explicitly shown, but you can infer it from sentences like "However, ratios of differences can be expressed" in the "Interval scale" section.

But really, it is a matter of mathematics. The problem with multiplications appears because of the "+273.15" part in expression like T (K) = T (°C) + 273.15. When computing differences:

ΔT (K) = T1 (K) - T2 (K)
       = (T1 (°C) - 273.15) - (T2 (°C) - 273.15)
       = T1 (°C) - T2 (°C) - 273.15 + 273.15
       = T1 (°C) - T2 (°C)
       = ΔT (°C)

The +273.15 offset vanishes in differences.

We need some kind of "absolute versus difference" construct in Quantity - this is the part required for resolving #95. To be formal we also need LevelOfMeasurement, but its value can be partially inferred from current API by testing:

if (unit.getConverterTo(unit.getSystemUnit()).isLinear()) {
    // unit scale is LevelOfMeasurement.RATIO
} else {
    // unit scale is LevelOfMeasurement.INTERVAL, ORDINAL or NOMINAL
}

So LevelOfMeasurement is conceptually required, but not strictly required because implementors can infer it from existing methods. However it may be useful for clarity.

[keilw]

If it is only an absolute vs. relative, how would an extra isAbsolute() or similar flag sound?

[desruisseaux]

An isAbsolute() method would work and allow us to solve #95. Alternatives are:

• Do the opposite: isRelative() or isDifference() or isDelta().
• Enumeration (would be clearer).
• Subtype of Quantity.
• Keep LevelOfMeasurement but tweak Steven's definitions of RATIO by explaining that a difference of temperature in °C may have RATIO scale. Such tweak may be a source of confusion however.
• Keep LevelOfMeasurement but add two values: DIFFERENCE and UNKNOWN. This would be a departure from literature however.
  • The DIFFERENCE value would be used for the "INTERVAL scale: operations applied on differences" cell in above table.
  • The UNKNOWN value would be used for the "ORDINAL scale: operations applied on differences" cell in above table.

[andi-huber]

Hi everyone, I did back off from this discussion around June (not without some frustration). You guys must be exhausted.

That said, I had a look on how Mathematica is dealing with our temperature problem. So this could be some inspiration ...

https://reference.wolfram.com/language/tutorial/TemperatureUnits.html

Cheers Andi!

[keilw]

@andi-huber Thanks, it does talk about "absolute" vs. "difference". And Wolfram seems to differentiate between those in the Dimension. Not sure, if it's the right place but worth a thought.

I'm not sure, if I would pollute the LevelOfMeasurement with the aspect of the absolute "dimension", "scale" or whatever we end up calling this?

Technically it would have a relatively small overhead. The impact of a simple boolean flag like isAbsolute() is also next to zero, while adding some enum e.g. to Quantity or anywhere else costs nearly 0.7kB extra bringing the JAR size from 39.9kB to about 40.6. It's not gigantic, but as we use other boolean methods in the API, does it really bring much benefit to add an enum that only provides a TRUE/FALSE information?

[desruisseaux]

Thanks Andi for the link. Indeed the Mathematica use of "absolute measurement" and "difference" is close to the proposal described in this issue. I note also that they do not use "Level of Measurement" terms, which seems consistent with my though that "Level of Measurement" and "absolute measurement versus difference" are two complementary things. However at this time I still not have a clear opinion about whether this approach would be better than tweaking Stevens's Level Of Measurements. Advices are welcome.

@keilw: if the size of the JAR file is such an issue, an easy way to save 6 kb would be to exclude the META-INF/maven/ entries added by Maven in the JAR file. They are Maven specific (non standard) and I'm not aware of any use of that.

[keilw]

@desruisseaux Every JSR and project that's built with Maven includes this folder, so better not rip that away. At some later stage, a few deprecated elements could be removed, but not before another true iteration, we must obey backward-compatibility. Issues like #39 if they also lead to method duplication would further increase the size for now.

If the "absolute/relative" property and the LevelOfMeasurement are complimentary, Steve's levels should not be tweaked. Extending Quantity btw. seems like the worst of all options, because all the quantity types like Temperature, Mass, etc. also directly extend Quantity, so while interfaces allow multiple inheritance, it may lead to ambiguities. Although the Wolfram link hints there may be some kind of sub-classing, it seems done on the Unit level there, with Kelvins vs. KelvinsDifference.

https://www.quora.com/What-are-absolute-units also answers the absolute vs. relative, gauge or offset question. The fact that there are so many opposing terms, but "absolute" is usually called the same speaks more for isAbsolute than isRelative, isGauge, isDifference, isOffset or isDelta ;-)

[keilw]

An interesting point both the Wolfram approach and Quora bring up is, that unlike LevelOfMeasurement (which those solutions using it associate with Measurement, Value Quantity) it talks both about the Unit.

Measurement units can be either absolute or relative

Followed by

However, physical measurements are often relative.

It is not conclusive about Unit vs. Quantity better using this kind of attribute, so to simply answer that I opened #140

[keilw]

Closing this, because we currently disregarded LevelOfMeasurement. Should a need arise again, the work was parked in the level_of_measurement branch and may be revisited again with new issue tickets.