axkr
si.properties was updated in tensor project
si.properties unit file was updated in tensor project
- https://github.com/datahaki/tensor/blob/master/src/main/resources/unit/si.properties
See also commit for autogenerated prefixes:
- https://github.com/datahaki/tensor/commit/ca3c103a5233bd1c434fa4729082743b80831435
the si.properties in Symja can be aligned:
- https://github.com/axkr/symja_android_library/blob/master/symja_android_library/matheclipse-core/src/main/resources/unit/si.properties
Create new QuantityTest.java in this folder:
- https://github.com/axkr/symja_android_library/tree/master/symja_android_library/matheclipse-io/src/test/java/org/matheclipse/io/system
do you happen to need a more stable SI unit api? javax/measure;unit-api;2.1.3;;y; tech/units;indriya;2.1.2;;y;
I personally don't have experience with these APIs. What is the current "Java standard"? What are the benefits of the Java API?
One requirement is, that we need "exact values" (no Java double values) in the exponents of unit definitions?
I am not sure about current "Java standard". From my viewpoint,having a more modular system that can adapt with the scientific definition is useful.
Since,any change on definition is gonna propagate to us as (configuration change)/(1000 lines of code difference). The key difference is on the design.
benefits of this Java API is it being a official implementation.Popularity and backward compatibility. The modularity for units is there.But the Java api is definitely slightly confusing. It can easily do a prefix conversion based on user input with the api. from nano to mili,or even year to second.
It however seems to fail our requirements though. https://github.com/unitsofmeasurement/si-units/blob/master/units/src/main/java/si/uom/NonSI.java
Quick look at UNIFIED_ATOMIC_MASS.shows that the precision is lower than Tensor's. and a quick look at LightYears proved the same.
maybe its better to keep the current tensor api.