Hi Martin,
My interest in Apache SIS started because of JSR-363, and got stronger after
our project started using gridded data.
The project I am working on is used for weather forecast, and is using
JScience. We are in the middle of some improvements, including moving to
JSR-363. I believe at the issue in the internal issue tracking system, I added
a link to a GeoAPI issue about it, from some time ago.
Quite interesting both tickets you linked, as well as the other issue linked,
where there's more comments.
I will try to add the ticket about JSR-363 to this sprint, or work on it after
working hours, to assess if what you ask for clarification would be helpful for
us as well, or if it would impact us in any way. After that, I will chime in to
vote/discuss.
Thanks for the heads up here in the mailing list
Bruno
From: Martin Desruisseaux <[email protected]>
To: Apache SIS <[email protected]>
Sent: Sunday, 17 June 2018 8:54 PM
Subject: On algebraic properties of units of measurement
Hello all
Apache SIS and GeoAPI depend on JSR-363, "Unit of Measurement"
specification. This specification is currently under revision. There is
of course many ways to design a unit API, but I think that the following
are beyond "arbitrary choices", as they impact our capability to do math
in software:
* The meaning of addition of two quantities (a number with a unit)
shall be the same for everyone. The specification should be specific
enough for ensuring that the result of "A + B" is equivalent
(ignoring rounding errors) in all implementations.
* If A = B, then A+C = B+C
* If A = B, then n*A = n*B
* A + B = B + A (addition commutativity).
While above seem obvious, it actually become tricky with temperature (°C
versus Kelvin). There is different ways to resolve the problem, but my
point is that no matter which solution we choose, it shall obey to above
laws. Otherwise I doubt we can do reliable mathematics with that JSR (it
is still okay if we refrain to use any Quantity operations). However
some JSR members are inclined to do nothing and keep above arithmetic
laws broken, for avoiding to change their implementation. I created two
tickets; if anyone on this list think that the above are important,
could you please add a vote on it?
* https://github.com/unitsofmeasurement/unit-api/issues/98
* https://github.com/unitsofmeasurement/unit-api/issues/99
Martin
