Solving Unit-1 is-equivalent-to Unit-2

[unitsofmeasurement]

Solving Unit-1 is-equivalent-to Unit-2

[andi-huber]

I think we can close this.

[andi-huber]

So I'd conclude, for any implementers to consider

• designing such a normal form
• and let UnitConverter.concatenate(UnitConverter converter) always produce a normal form

[keilw]

Thanks for pointing that out. Either for the Spec or UoM Guidebook I assume some of this information will also help.

[desruisseaux]

I propose an amendment to the first point:

• Two Units of the same quantity are equivalent if by replacing one with the other you achieve equivalent numerical results when doing quantity calculus.

For example kilometre and kilowatt have the same UnitConverter to their system unit (their converters can even be the same instance) but are not equivalent.

I agree that implementations should produce normal forms. In the case of unit conversions, this is simplified by the fact that the vast majority of conversions are linear, in which case commutativity (among other) applies. However one difficulty we have with current API is that UnitConverter.isLinear() method specification is wrong. Its current specification said:

Indicates if this converter is linear. A converter is linear if:

• convert(u + v) == convert(u) + convert(v)
• convert(r * u) == r * convert(u)

It is not the usual definition of linear conversion since a converter of the form y = scale * x + offset would not comply to this definition. This prevent implementations to detect e.g. that commutativity applies for Celsius units for instance.

[andi-huber]

@desruisseaux thanks for the hint, I've updated the description.

[andi-huber]

Regarding UnitConverter.isLinear(): This could be superseded by something like UnitConverter.characteristics() to return a set of enums like Java's Collector does ...
https://docs.oracle.com/javase/8/docs/api/java/util/stream/Collector.Characteristics.html

[keilw]

We could add new methods but should not remove any without deprecating them first. Pulling MetricPrefix from the RI into the API was already a bit of a challenge but i was not removed and the package name also changed, so existing code may be migrated with little changes to impor statements. Completely removing a method would only work another version down the road.

[andi-huber]

Sorry, I did not mean to start a naming discussion.
Just as a side-note: isLinear will be used rather by API implementers than by API users.

[keilw]

Actually @desruisseaux started it already #39

[keilw]

@andi-huber Is there anything to do here?

[keilw]

Thanks