Vector Quantity Support
fpoolev opened this issue · 8 comments
Are there plans to create multidimensional quantities? I'm looking for a replacement for JScience VectorMeasure.
http://jscience.org/api/javax/measure/VectorMeasure.html
Thanks!
Thanks for the suggestion. It is not so likely the API (as javax.measure in JSR 275/JScience 4) will get a VectorQuantity or similar. I made a concrete suggestion for a "Compound Unit" unitsofmeasurement/unit-api#45 because a somewhat similar analogy exists in Java SE 8 (TemporalAmount) and JSR 275 also had this before.
The Measurement interface and classes in JSR 363 are different and use Quantity, adding further details like a timestamp.
Another implementation Apache SIS has a https://github.com/apache/sis/blob/trunk/core/sis-utility/src/main/java/org/apache/sis/measure/Scalar.java. I could not find a Vector there either, but feel free to ask. Unlike JScience whose fate seems a bit unclear, SIS is one of the most active implementations of JSR 363 other than the official ones like the RI.
@desruisseaux, @dautelle What do you think of the idea? I know concrete use cases for a "Compound Unit" (as described, the most compelling ones are heights like 5 ft 10 in common at least in the US and a few other countries) but I am not so sure about Vector Quanties.
I think that "Compount Unit" and vectors are different things. I think (please correct me if I'm wrong) fpoolev was talking more about vector in "vector algebra" sense. For example an ocean current vector (3, 4) m/s is a current having a East/West component flowing at 3 m/s and a North/South component flowing at 4 m/s; the total current magnitude is 5 m/s (i.e. √(3² + 4²)).
Such vectors are indeed very useful, but they are not alone. After vector, we may want to do matrix. Then after matrix, we may want to do tensor. We may also want to do remote sensing images (which may be seen as matrix or tensor), we could also attach unit to ranges or fractions, etc. So how to decide where to stop (e.g. do vector but not tensor)?
Yes, they are two different things. I created unitsofmeasurement/unit-api#45 to consider a CompoundUnit or similar type for a future version of the JSR. In theory it could also be on an implementation level first, there's nothing wrong with adding the class to either RI or maybe uom-se earlier. However, it is also worth a though if Unit.compound() was of value to the API in a future release.
Do you think for an implementation similar to http://jscience.org/api/javax/measure/VectorMeasure.html was worth considering for either uom-se or the RI?
The example in JScience actually combines the vector with Unit.compound() but they can be used independently of course.
I think @desruisseaux described what I had in mind. I am looking for a representation for 3D vectors like accelerometer and gyroscope where the unit is common across dimensions. If you were interested, you may be able to kill two birds with one stone - implement matrix and then a vector is simply a type of matrix.
I think for Compound units it makes sense (very useful for formatting, e.g. hour/min/sec). As for VectorMeasure, this would be openning the Pandora box!
Quantity (more specifically Quantity Type) are intended to be used as parameter for generic user types. It is up to the users to create their own Vector/Matrix type (parameterized) and not the API.
Otherwise It would be an uncontrollable extension (e.g. you will be asked to provide vector / matrix operations, etc.)
of
Thanks everyone for the assessment. Compound units also to bein sync with e.g. JSR 310 for Java SE are on the roadmap for new API releases: https://github.com/unitsofmeasurement/unit-api/issues
Let's wait for JavaOne and the SI Conference also taking place in October. Then either a MR or even new JSR (1.1 most likely, it may not have revolutionary new changes) sounds like a good idea to think about.