Arithmetic operations should be done in system units for certain scales

[filipvanlaenen]

Implementation of unitsofmeasurement/unit-api#95 and unitsofmeasurement/unit-api#131 in Indriya.

Some examples of the expected behavior:

• 0 ⁰C + 0 ⁰C = 273.15 ⁰C
• 0 ⁰C × 0 ⁰C = 74,610.9225 ⁰C²
• 0 ⁰C × 2 = 273.15 ⁰C
• 273.15 ⁰C / 0 ⁰C = 2 one
• 0 ⁰C / 2 = -136.575 ⁰C

Needs unitsofmeasurement/unit-api#95
Also see https://github.com/unitsofmeasurement/unit-api/wiki/Arithmetic-rules-for-Difference-versus-Absolute-quantities

[keilw]

I certainly would not do that for every single operation. It is a burden and hassle having to convert 1mi+5in to metre first and then back (to WHAT?) So doing this requires the distinction between the "level" of unit/quantity (Nominal, Ordinal, Interval,...) as in 4. of the last check-list in #95.

If you plan to do this for Temperature only, why not, but please let's wait till all the items are worked on in a particular order.

[desruisseaux]

Actually it does not depends on the level of quantity (Interval versus Ratio). In current state of Unit API, all Quantity instances are assumed to have Ratio level, which is why conversion to system unit is conceptually required for all of them (not only temperature), skipping that conversion only when the implementation can determine that the result would be equivalent. Specifying the level of quantity is a separated issue.

This issue is already fixed in Apache SIS implementation of units of measurement without additional burden and without the need to perform any special case for temperature. I will try to copy the code to seshat this week.

[keilw]

Well then let's park this till we see, how Seshat deals with it. The users do expect the same behavior for a majority of units, so a 1mi+5in calculation should be in MILES until we introduced something like a target unit for that calculation.

[keilw]

Please note, while scheduled for 2.0 of course, both this ticket and #124 (which is currently considered prio1, but there are other UnitFormat implementations that can deal with it, so there is a workaround and it only occurs with newly introduced labelled units) should either be solved within 2-3 weeks, otherwise we can't have it in EDR1. And the EDR must be published within 9 months, which is reached in September, so no later than the last week of August everything else goes into the Public Review stage (that is another 6 months later, we should aim for end of the year to be ready for the SI reforms in early 2019)

[filipvanlaenen]

I found out that we probably have to do the arithmetic in BigDecimal (both for correct precision and overflow handling) and with some conversion anyway, and since I'm moving this code into a single class, implementation would be relatively simple. I had it working for multiplication (quantity × quantity), but haven't had time to check it in and create a pull request.

[keilw]

Are any other PRs or tickets related to this one? Have not tried for a PR, but issues in Waffle can be marked as needs #X or requires #Y (only in the first description field), so they are connected in the Waffle Kanban board.