unitsofmeasurement / indriya Goto Github PK
View Code? Open in Web Editor NEWJSR 385 - Reference Implementation
License: Other
JSR 385 - Reference Implementation
License: Other
Example (currently failing):
IntegerQuantity<ElectricResistance> oneIntOhm = new IntegerQuantity<ElectricResistance>(Integer.valueOf(1).intValue(), Units.OHM);
LongQuantity<ElectricResistance> oneLongOhm = new LongQuantity<ElectricResistance>(Long.valueOf(1).longValue(), Units.OHM);
Quantity<ElectricResistance> sum = oneIntOhm.add(oneLongOhm);
assertEquals(LongQuantity.class, sum.getClass());
IntegerQuantity + LongQuantity
should result in a LongQuantity
, just like LongQuantity + IntegerQuantity
currently results in a LongQuantity
.
The widening should probably be as follows (transitively):
byte → short → int → long → BigInteger
float → double → BigDecimal
any integer type → any decimal type
This behavior should apply to addition, subtraction, multiplication and division.
Set up a CI instance for Indriya
Should we add the Maven plugin for PIT, so we can use mutation testing to check unit test code coverage?
Info about PIT: http://pitest.org/
How to add the plugin: http://pitest.org/quickstart/maven/
Currently to reuse it across different implementations, BinaryPrefix resides in uom-lib-common. While Indriya is likely to use much of that library also in 2.0 we could move BinaryPrefix
to the unit
package next to MetricPrefix
, too.
EBNFUnitFormat takes TransformedUnit into consideration, especially if a symbol was set. SimpleUnitFormat currently does not use the symbol unless the same string is also applied as label.
Add a BigIntegerQuantity
type for large integer numbers.
With JUnit 5 offering many new and advanced features, it seems a good idea to adopt the new version.
See unitsofmeasurement/uom-se#180
Rest under #7
This is related to unitsofmeasurement/unit-api#45 on the API level.
The code coverage is currently 40%, see codecov badge. We should create more JUnit tests especially in packages with a very low coverage. At least 60% like the JSR 363 RI should be archived, if more, even better.
The package-info contains old or badly formatted content like
Hi,
I did a bit of brush-up to Indriya over the holidays. And through JUnit tests for CompoundUnit
a problem occurred to me we should rethink the need for a CompoundUnit
as opposed to something like a CompoundQuantity
.
It is currently possible to create a compound chained across even multiple steps like HOUR.compound(MINUTE).compound(SECOND)
. However, trying to combine this type of Unit
into the current Quantity
, how to handle "1 hour: 5 minutes: 30 seconds"
, if only the unit part is multidimensional? We may need something along the lines of a CompoundQuantity
. JSR 310 TemporalAmount
could be a very vague inspiration, but we should ask ourselves questions like do we need a List
or Set
of units, because TemporalAmount
states
The list of units completely and uniquely represents the state of the object without omissions, overlaps or
duplication
Which would speak for a Set avoiding duplication.
Either way, it seems we have to think about that and come up with an idea how to best combine a "list" of Unit elements and numeric values attached. JSR 310 TemporalAmount
implementations are overly simplified, they do not allow more than 2 or 3 distinct units each. E.g. "Year, month, day" in case of the Period
. We need a more flexible approach for general purpose unit support.
The helper class Calculus
is quite similar to e.g. NaturalQuantityComparator
which also resides in the function
package. The top level package is primarily for abstract base classes.
Following its addition with #26 there should be more JUnit tests for BinaryPrefix.
If there is a large difference in the metric prefixes such that overflow becomes possible, the implementation of the addition and the subtraction is too naive.
Example using IntegerQuantity:
2 YΩ - 1 yΩ = 2 YΩ (correct)
2 yΩ - 1 YΩ = -2147483645 yΩ (incorrect, should have been -1 YΩ)
The implementations should cast the values to the largest metric prefix, not the metric prefix of the first element.
Similar to https://github.com/unitsofmeasurement/unit-api/tree/gh-pages for the API
To make Indriya backward-compatible with other Java versions (at least SE 8, maybe also 7) and explore new features in upcoming versions of the JDK, we plan to support the Java 9 Multi-Release JAR feature.
This blogpost by JSR 380 Spec Lead Gunnar http://in.relation.to/2017/02/13/building-multi-release-jars-with-maven/ may help. Seems either for Bean Validation or other Hibernate projects he already used that.
Also an interesting lead is this GitHub project: https://github.com/metlos/multi-release-jar-maven-plugin
After AbstractQuantityFormat has its new name it should implement a QuantityFormat
interface from the API.
In this line, the hash is the sum of dividend
is added to itself. I think it should be the sum of dividend
added to divisor
.
Right now AbstractQuantityFormat is a factory for package-local concrete implementations. This is less flexible for extensions outside the RI, so similar to UnitFormat implementations each concrete class should be able to instantiate itself.
The System class Units
returns WATT
as AlternateUnit
. it should be just a Unit
.
It should include:
The SI redefinition https://www.euramet.org/publications-media-centre/news/?tx_news_pi1%5Bnews%5D=637&tx_news_pi1%5Bcontroller%5D=News&tx_news_pi1%5Baction%5D=detail&cHash=d1b21b8e8a4522f5cfcf3b101a095f04 makes elementary constants like the Avogadro constant, Planck constant or Elementary charge more important than they already used to be.
Right now a few of them are defined internally in the NonSI class of the SI Units module.
Given their increased role, we could either:
Both ComparableQuantity
and ComparableUnit
interfaces have an isEquivalentOf()
method. Should we keep that name or use a shorter version like:
According to Oxford English using "of" or "to" depend, if "equivalent" is used as adjective or noun. We should decide which one better applies here.
Please select from the following options:
Follow-up to unitsofmeasurement/uom-se#145
It should return 1,001 mΩ on 1 Ω + 1 mΩ.
Update headers for JSR 385.
Java 10 just went Final: https://www.oracle.com/corporate/pressrelease/Java-10-032018.html
Let's test it with Indriya and the current JSR 385 snapshot to see, if there are any side-effects or issues.
Of the (very few) features introduced with Java 10, the local variables are certainly something we must evaluate against JSR 385 to ensure, units and quantities work well with the new var
declaration.
Not sure about Class-Data-Sharing, it could mean some performance-benefit, if e.g. JSR related classes are shared at the right time, but mabe a bit less crucial than local variables.
Right now AnnotatedUnit
is not properly supported by SimpleUnitFormat
while it works in other UnitFormat
implementations like EBNFUnitFormat
.
Right now the string representation of any Unit
based on AbstractUnit
uses SimpleUnitFormat
in its default variant.
There was an attempt to make this dynamically use the current UnitFormat
of the current ServiceProvider
, but it had unpredictable and unwanted side-effects that could lead to initialization of AbstractUnit being prevented. Since a chain of different modules may have a similar effect, it is not too likely to work here in the future either (if you feel you have a working, stable answer, please propose it)
However, it should be possible to offer a simple and easy tweak, e.g. via System properties to select e.g. between:
All of which are build in.
Right now all Unit
classes rely on UnitFormat.label()
if the string representation needs to be altered or overriden. TransformedUnit
also defines a symbol, but it does not seem used when formatting. Also see unitsofmeasurement/uom-se#188
Currently SystemOfUnits
has a descriptive name and getName()
method. Although registered under a key and possible aliases (currently this is implementation-specific, using the getter in the SPI interface) the UnitFormat
implementation class only has a class name. Which may not always be a nice, human-readable string. Overriding toString()
can help, so this could be sufficient, but let's discuss the question of a descriptive string when new versions of the API arise.
To be in better sync with the API the initial version should be 1.0. This version fully implements Unit-API 1.0 until the new version is created.
Before the "tech" domain became available after March 2015 the RI and TCK used a "virtual" domain name units.tec
I registered instead. Since then units.tech
is also registered. While the "tec" domain is fairly cheap, it won't work as a URL, it is just virtual.
Should we use the 2.0 release and switch to units.tech
instead?
Depending on the choice for Indriya, the new TCK would also match its package namespace.
I recently stumbled on some pretty nasty behavior that I think should probably be changed.
What does the following return?
public Quantity<Length> scale(Quantity<Length> q) {
return q.multiply(Math.sqrt(2));
}
Unfortunately, it depends. If you pass in an IntegerQuantity, you end up with exactly the same value you passed in, because IntegerQuantity truncates before multiplying: https://github.com/unitsofmeasurement/unit-ri/blob/master/src/main/java/tec/units/ri/quantity/IntegerQuantity.java#L91
But, Quantities.getQuantity(...) returns the same static type independent of the type of the number you pass in, which makes this behavior very surprising.
This seems very dangerous, especially for a library whose main point is to avoid silent calculation bugs due to unit mismatch...
To match the underlying SimpleUnitFormat, DefaultQuantityFormat should better be called SimpleQuantityFormat
The abstract base class QuantityFormat
should be renamed to AbstractQuantityFormat
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.