You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The result of Quantity.add(Quantity) shall be numerically equivalent for all implementations. "Numerically equivalent" means that they shall have the same numerical value (ignoring rounding errors) after conversion to the same unit by Quantity.to(Unit).
Example: 1 m + 2 cm = 1.02 m or 102 cm, at implementation choice. But can not be 2 meters.
The problem become more tricky with temperature: 1°C + 2°C may be 3°C or 276.15 °C, depending on whether the 1°C and 2°C quantities are temperature measurements or temperature increments. It is not the purpose of this issue to decide which interpretation should be applied. The purpose of this issue is to state that whatever interpretation is choose, the specification should describe it with enough details for ensuring that all implementations produce numerically equivalent results.
The text was updated successfully, but these errors were encountered:
Following phone call on Thursday 21th 2018, I believe there is an agreement that arithmetic operations shall obey to arithmetic laws. This implies a determinist behavior of A + B, since there is not many ways to implement Quantity arithmetic operations in an arithmetically consistent way. Closing this issue as "accepted in principle". Concrete action will be a merge request with Javadoc updates along the line of the Arithmetic operations shall obey arithmetic laws wiki page. See #95 for discussion.
The result of
Quantity.add(Quantity)
shall be numerically equivalent for all implementations. "Numerically equivalent" means that they shall have the same numerical value (ignoring rounding errors) after conversion to the same unit byQuantity.to(Unit)
.Example: 1 m + 2 cm = 1.02 m or 102 cm, at implementation choice. But can not be 2 meters.
The problem become more tricky with temperature: 1°C + 2°C may be 3°C or 276.15 °C, depending on whether the 1°C and 2°C quantities are temperature measurements or temperature increments. It is not the purpose of this issue to decide which interpretation should be applied. The purpose of this issue is to state that whatever interpretation is choose, the specification should describe it with enough details for ensuring that all implementations produce numerically equivalent results.
The text was updated successfully, but these errors were encountered: