Same Units considered different

[keilw]

• Create Wiki page
• Copy/Move relevant portions of the Equality documentation to the [UoM Guide]
  (https://github.com/unitsofmeasurement/uom-guide)
• Mention this problem in the Specification, probably in a new chapter

See unitsofmeasurement/uom-se#164

[keilw]

Related to #4

[andi-huber]

UnitConverters PiMultiplierConverter and PiDivisorConverter can be consolidated into a single PiPowerConverter, that is similar to the existing PowerConverter but uses Math.PI as base.
This would simplify the composition table and also allow for simpler composition implementation.

[keilw]

I would not see them as extensions to PowerConverter but PiMultiplierConverter does a lot similar to MultiplyConverter.

[andi-huber]

@keilw yes, these converters all represent multiplication. However, PiMultiplierConverter and PiDivisorConverter do know how to properly handle multiplication of BigDecimal with PI or 1/PI, which the MultiplyConverter does not.

To clarify what I'm aiming for is that composition of these Pi converters can be simplified eg
PI_MUL * PI_MUL * PI_MUL -> PI^3
PI_DIV * PI_DIV * PI_DIV -> PI^-3
PI_MUL * PI_MUL * PI_DIV * PI_DIV -> PI^0 = IDENTITY

[keilw]

Unfortunately 40 tests are failing, I disabled the class in question, because the Indriya build on master should not constantly fail. I personally don't have a problem with a name like PiPowerConverter, but the JavaDoc should say more about the "power" aspect, if it just reads "multiply by Pi" the name seems misleading.

[andi-huber]

Started a wiki page to document the background required for solving this issue.
https://github.com/unitsofmeasurement/indriya/wiki/Unit-Equivalence

[keilw]

Great, thanks. Some of that may eventually go either into the Spec or UoM Guide Book.

[andi-huber]

Extending the corresponding wiki page with thoughts on Simplification Rules
https://github.com/unitsofmeasurement/indriya/wiki/Unit-Equivalence#simplification-rules

I conclude 2 things:

1. We need some kind of an 'intermediate normal-form' that keeps all information of the original transformations used for a composition, without loss of precision, so that we can do further compositions and simplifications properly. (That's the state of the current implementation, it yields such an intermediate normal-form.)
2. We need a 'fully simplified normal-form' for actual calculus and test for equivalence. (Also applying simplification-rules as mentioned above.)

[keilw]

Some of it may be subject to a Spec chapter.

[andi-huber]

Wiki: Filling in the gaps ...

Explaining unit-converter equivalence:
https://github.com/unitsofmeasurement/indriya/wiki/Unit-Equivalence#decide-ability-of-equivalence

Explaining the 'normal-form' yielding algorithm:
https://github.com/unitsofmeasurement/indriya/wiki/Unit-Equivalence#implementing-a-normal-form-yielding-composition-algorithm

[keilw]

@andi-huber Is there any more work here or are the other bullet points also done?

[andi-huber]

We have implemented Unit.equals in RI according to the write-up https://github.com/unitsofmeasurement/indriya/wiki/Unit-Equivalence.

The other bullet points are not done, not by me.

[keilw]

The part about the Specification is on the critical path towards 2.0 (https://www.bipm.org/en/about-us/ shows, there will be a critical maintenance of the site between April 19 and 23, I bet it has something to do with SI reforms and it's good to wait until after that before we finalize the sped and possibly update links that may have changed)

The other tasks may also happen later if necessary.

[keilw]

Anything still open here?

[keilw]

Created unitsofmeasurement/uom-guide#5 for item 2, closing this.