Giter Club home page Giter Club logo

djunits's Introduction

djunits

Delft Java UNIT System

DJUNITS is a set of Java classes that make life easy for scientific software writers by catching many common errors at compile time and some others at runtime.

  • DJUNITS performs automatic conversions between most commonly used units of the same type. E.g., conversion of distances from Miles to kilometers.
  • DJUNITS stores all values internally in the basic SI unit for that quantiry. The value can be converted to any (user-selectable) suitable unit for display.
  • DJUNITS distinguishes Absolute and Relative values to catch common errors at compile time,
  • DJUNITS ensures that quantities expressed in different (but compatible) units are correctly added together. E.g. a distance in Miles is correctly added to a distance in kilometers.
  • DJUNITS knows or computes the SI type of the result when a value in one unit is multiplied, or divided by another value (that may have another unit),
  • DJUNITS handles Scalars, Vectors and Matrices.
  • DJUNITS stores almost everything in immutable objects. Vectors and Matrices also come in a Mutable variant where the stored values can be modified one by one or all at once.
  • DJUNITS stores values as Float or Double values.

Origin

DJUNITS was developed at the Delft University of Technology as part of the Open Traffic Simulator project (started in 2014).

In August 2015 it became obvious that the units and values classes developed for the Open Traffic Simulator were sufficiently mature to be used in other projects.

The main authors/contributors of the DJUNITS project are Alexander Verbraeck and Peter Knoppers.

Absolute and Relative values

Values in DJUNITS are either Absolute or Relative.

An Absolute value is a value measured from a standard reference. For geographical directions North and East should be Absolute values. Adding two absolute values together makes no sense. Subtracting one absolute value from another does make sense (and results in a Relative value). Subtracting East from North should result in an angle of ±90° or ±π/2 (depending on the unit used to express the result). An absolute unit needs reference to be useful. Values subtracted from each other need to know their reference to be able to carry out the subtraction.

A Relative value expresses the difference between two (Absolute or Relative) values. The angle in the example above is a Relative value. Relative values can be added together and subtracted from each other (resulting in Relative values). Adding a Relative value to an Absolute value results in an Absolute value. Subtracting a Relative value from an Absolute value also results in an Absolute value.

In the geographical example, directions are Absolute and angles are Relative. Similarly, when applied to lengths, positions are Absolute and distances are Relative.

Generally, if adding a value to itself makes no sense, the value is Absolute; otherwise it is Relative.

Operation Operands Result
+ (plus) Absolute + Absolute Not allowed
+ (plus) Absolute + Relative Absolute
+ (plus) Relative + Absolute Absolute
+ (plus) Relative + Relative Relative
- (minus) Absolute - Absolute Relative (corresponding quantity)
- (minus) Absolute - Relative Absolute
- (minus) Relative - Absolute Not allowed
- (minus) Relative - Relative Relative
* (times) Absolute * Absolute Not allowed
* (times) Absolute * Relative Not allowed
* (times) Relative * Absolute Not allowed
* (times) Relative * Relative Relative (different quantity)
/ (divide) Absolute / Absolute Not allowed
/ (divide) Absolute / Relative Not allowed
/ (divide) Relative / Absolute Not allowed
/ (divide) Relative / Relative Relative (different quantity)

Attempts to perform operations that are marked not allowed are caught at compile time.

All quantities make sense as Relative values. The four quantities that also make sense as Absolute values are listed in the table below.

Quantity Absolute interpretation Absolute class
and Unit
Relative interpretation Relative class
and Unit
Length Position Position
PositionUnit
Distance Length
LengthUnit
Angle Direction or Slope Direction
DirectionUnit
Angle (direction or slope difference) Angle
AngleUnit
Temperature Temperature AbsoluteTemperature
AbsoluteTemperatureUnit
Temperature difference Temperature
TemperatureUnit
Time Time (instant) Time
TimeUnit
Duration Duration
DurationUnit

The use of Absolute in relation to Temperature here may be confusing. In the table above, an absolute temperature is not necessarily expressed in Kelvin. E.g. the melting temperature of water at normal atmospheric pressure is an Absolute value (it does not make sense to add this temperature to itself). In DJUNITS this value would internally be stored as 273.15 K, but on display it may be converted (back) to Celsius and displayed as 0 °C. A temperature difference of 5 K (Kelvin) is a Relative, even though Kelvin is often called absolute temperature.

Dimensionless is a special relative unit in DJUNITS that has a unit of 1.

Units

DJUNITS has a large number of pre-defined units. Internally, all values are stored in SI-units or an equivalent standard unit. For scalar values, the field is called si and can be retrieved as it is a public (immutable) field. Alternatively, the getSI() method can be used. The internal storage in SI units allows addition and subtraction of values that have been initialized using different units. Formatting and expressing the unit can be done using any defined unit. The code below illustrates some of the features.

Speed speed1 = new Speed(30, SpeedUnit.MILE_PER_HOUR);
System.out.println("speed1:     " + speed1);
Speed speed2 = new Speed(10, SpeedUnit.METER_PER_SECOND);
System.out.println("speed2:     " + speed2);
Speed diff = speed1.minus(speed2);
// Default display unit will be SI unit for speed:
System.out.println("difference: " + diff); 
// Change default display unit; internal SI value is unaltered:
diff.setDisplayUnit(SpeedUnit.MILE_PER_HOUR); 
System.out.println("difference: " + diff);
// Works, but not mistake-safe:
System.out.println("difference: " + diff.getInUnit(SpeedUnit.KNOT) + " kt"); 
// Safer:
System.out.println("difference: " + diff.toString(SpeedUnit.KNOT)); 
// Programmer must be really sure that SI-unit is m/s:
System.out.println("difference: " + diff.si + " m/s (si)"); 
// Same as previous:
System.out.println("difference: " + diff.getSI() + " m/s (si)"); 
// Safer:
System.out.println("difference: " + diff.toString(SpeedUnit.SI) + " (si)"); 
System.out.println("difference: " + diff.toString(SpeedUnit.KM_PER_HOUR));

This would create the following output:

speed1:     30.0000000 mi/h
speed2:     10.0000000 m/s
difference: 3.41120000 m/s
difference: 7.63063708 mi/h
difference: 6.630842332613389 kt
difference: 6.63084233 kt
difference: 3.411199999999999 m/s (si)
difference: 3.411199999999999 m/s (si)
difference: 3.41120000 m/s (si)
difference: 12.2803200 km/h

When a class implements the interface UNITS (org.djunits.unit.UNITS), all defined units are available without the prefix XxxUnit. So, in that case a Length can be defined as new Length(12.0, METER) instead of Length(12.0, LengthUnit.METER).

Multiplication and Division

Multiplying or dividing physical quantities produces a result in a different physical unit. There is no general way (we could think of) where the Java compiler can check the type of the result in the general case. Therefore DJUNITS has an extensive list of built-in multiplication and division operations with known result type. For instance

Speed speed = new Speed(50, SpeedUnit.KM_PER_HOUR);
Duration duration = new Duration(0.5, DurationUnit.HOUR);
Length distance = speed.multiplyBy(duration);
Acceleration acc0 = speed.divideBy(duration);
Area area = distance.multiplyBy(distance);
Volume vol = area.multiplyBy(distance);

DJUNITS knows that the result of multiplication of a speed and a time is a distance. The value of distance is 2500 m.

Although we're not entirely sure, we believe that there is never a need for multiplication or division with an Absolute operand. It just does not make sense to multiply 23 September 2015, 3 PM (an absolute Time) by 2...

Catch mistakes at compile time where possible

DJUNITS is designed to protect the programmer from easily made mistakes:

Speed speed = new Speed(12, SpeedUnit.KM_PER_HOUR);
Length length = new Length(4, LengthUnit.MILE);

// Good:
Duration howLongOK = length.divide(speed); 

// Does not compile; result would be a frequency:
Duration howLongWrong = speed.divide(length); 

// Does not compile; subtracting a length from a speed make no sense:
Speed other = speed.minus(length); 

// Throws a UnitRuntimeException:
Acceleration acceleration = speed.times(speed).asAcceleration(); 

// OK:
Energy kineticEnergy = speed.times(speed).times(new Mass(3, MassUnit.KILOGRAM)
    .times(0.5)).asEnergy(); // OK

The mistakes on the lines with comments starting with Does not compile will be caught at compile time. In a development environment that continously checks for coding errors (like eclipse) such mistakes will be marked in by the java editor.

The before-last line multiplies a speed by another speed. The result of this operation is not something that DJUNITS supports directly. Such scalars can be cast to something DJUNITS does know of with an asXxx method. Whether that cast is permitted can only be checked at runtime and this example would fail with a UnitRuntimeException: cannot cast 11.1111111 m2/s2 to Acceleration.

A correct example where DJUNITS does not know the unit of the result (thus requiring an asXXX() cast) is:

Energy kineticEnergy = speed.times(speed).times(new Mass(3, MassUnit.KILOGRAM)
    .times(0.5)).asEnergy(); // OK
System.out.println(kineticEnergy);

This would print:

16.6666667 J

Scalars, Vectors and Matrices

Simple values are referred to as scalars. DJUNITS also handles groups of values (these must all be of the same unit) as vectors or matrices. Vectors and matrices come in four varieties:

  • Dense, Immutable
  • Dense, Mutable
  • Sparse, Immutable
  • Sparse, Mutable

Dense vectors and matrices use arrays to store the values. Sparse vectors and matrices use an indexed structure to store only the non-zero values. Numeric 0.0 values are not stored explicitly in Sparse vectors and matrices. Very large vectors and matrices with lots of 0.0 values are more efficiently stored in Sparse organization.

Immutable vectors and matrices do not provide methods to change any of their values. Mutable vectors and matrices have methods to update their values. Changing values from or to zero in mutable sparse vectors or matrices is a slow operation.

Doubles and Floats

The Java double precision floating point value takes 8 bytes of memory, the float value takes 4 bytes. Both are available in DJUNITS. The typed double values use no special prefix indicating their precision. So the scalar type that stores a speed as a double is named Speed. Similarly, SpeedVector and SpeedMatrix store their values in double arrays. DJUNITS types that use Floats to store their (si) values have class names prefixed with Float. The float speed scalar class is therefore FloatSpeed, and the equivalent vector and matrix classes are FloatSpeedVector and FloatSpeedMatrix.

Extensions

Several extensions are under consideration:

  • Typed vectors and matrices, so a LengthMatrix can be multiplied with the inverse of a DurationMatrix (units in 1/s) to give a SpeedMatrix. This can be cell-cell multiplication (n x m matrix 'times' an n x m matrix yielding an n x m matrix) or real matrix multiplication (n x m matrix times an m x p matrix yielding an n x p matrix).
  • Adding complex scalars, vectors and matrices. With the code generator, it should be quite easy to ready DJUNITS for complex typed scalars, vectors, and matrices.
  • Adding BigDecimal scalars, vectors and matrices. With the code generator, it should be quite easy to ready DJUNITS for BigDecimal typed scalars, vectors, and matrices.

Documentations and test reports

DJUNITS documentation and test reports for the current version can be found at https://djunits.org/docs/latest. The manual is at https://djunits.readthedocs.io, or at https://djunits.org/manual The API can be found at https://djunits.org/docs/latest/apidocs/index.html.

djunits's People

Contributors

averbraeck avatar

Stargazers

 avatar

Watchers

 avatar  avatar

djunits's Issues

Printing of Scalar using a Locale is not working properly

LocaleDemo clearly shows that the printing (and probably parsing) of scalars using a Locale is NOT working. The code is as follows:

        Locale.setDefault(Locale.forLanguageTag("NL"));
        Duration hour = new Duration(3.0, DurationUnit.HOUR);
        System.out.println(hour.toTextualString());
        System.out.println(hour);
        Locale.setDefault(Locale.US);
        System.out.println(hour.toTextualString());
        System.out.println(hour);

Output is:

3.0 h
3,00000000 h
3.0 h
3.00000000 h

Where the expected output on the first two lines is:

3,0 u
3,00000000 u

So, none of the lines is correct...

Update libraries to latest version (fewer bugs and vulnerabilities)

Libraries:

  • djutils-base 2.2.0 -> 2.2.1
  • junit 5.10.0 -> 5.10.2
  • jakarta-annotations 2.1.1 -> 3.0.0

plugins:
The maven dependencies in the pom file have also been updated to the latest version:

  • maven-compiler-plugin 3.10.1 -> 3.13.0
  • maven-site-plugin 3.12.1 ok
  • maven-install-plugin 3.0.1 -> 3.1.1
  • maven-source-plugin 3.2.1 -> 3.3.1
  • maven-javadoc-plugin 3.4.1 -> 3.6.3
  • maven-resources-plugin 3.3.0 -> 3.3.1
  • maven-checkstyle-plugin 3.1.2 -> 3.3.1
  • checkstyle 8.35 -> 10.15.0
  • maven-surefire-plugin 3.0.0-M7 -> 3.2.5
  • maven-surefire-report-plugin 3.0.0-M7 -> 3.2.5
  • maven-failsafe-plugin 3.0.0-M7 -> 3.2.5
  • jacoco-maven-plugin 0.8.8 -> 0.8.12
  • spotbugs-maven-plugin 4.7.1 -> 4.8.4.0
  • spotbugs 4.7.1 -> 4.8.4
  • maven-project-info-reports-plugin 3.4.0 -> 3.5.0
  • maven-jxr-plugin 3.2.0 -> 3.3.2
  • taglist-maven-plugin 3.0.0 ok
  • maven-pmd-plugin 3.17.0 -> 3.22.0
  • maven-changes-plugin 2.12.1 ok
  • flatten-maven-plugin 1.3.0 -> 1.6.0
  • maven-deploy-plugin 3.0.0 -> 3.1.1
  • nexus-staging-maven-plugin 1.6.7 -> 1.6.13
  • maven-gpg-plugin 1.5 -> 3.2.4

Change unit for printing a dimensionless SiScalar to be blank

Currently, a dimensionless SIScalar prints a unit of '1'. Now that the Dimensionless prints a blank unit, the SIScalar has to be changed as well to be consistent. As an example, the following code:

  SIScalar s1 = Torque.of(1.33, "N.m").divide(Energy.valueOf("2.1 J"));
  System.out.println("|" + s1 + "|");

prints:

|0.63333333 1|

Typo in name of constant PLANKREDUCED

Planck is written with a "c" as the before-last letter. The constant for Plancks constant in Constants.java has this correct. The derived value PLANKREDUCED (Plancks constant divided by 2 pi) got it wrong.

Break the circular dependency between djunits and djutils

The djunits project was made dependent on djutils, to avoid code duplication for the Throw, Try, URLResource and NumberParser classes. Also, the tinylog Logger and CategoryLogger can be used by djunits now.

On the other hand, djutils is dependent on djunits for the djutils-cli, djutils-data, djutils-eval, and djutils-serialization modules that all use djunits.

The problem is that we now cannot make a new release of djunits that uses the latest version of djutils while releasing the latest version of djutils that is dependent on the latest version of djunits. One of them will always use the one-but-last version...

There are three (and possible more) solutions. @WJSchakel and @OTSim : seeking your input on this.

  1. As before, copy the few classes that djunits needs into djunits. To make it more clear, we could even give the classes the path org.djutils. When changes in djutils occur, just copy the verbatim code into djunits. This way, djunits also stays 'clean' and is dependent on as few other packages as possible. Advantage: easy, and no overhead taken into djunits. Disadvantage: code duplication and possible inconsistencies between projects.
  2. Separate out the base djutils package as a separate project. This way, both djunits and the rest of djutils can be dependent on this project. Advantage: clean solution without code duplication. Disadvantage: more projects to maintain, and losing the tight integration n the djutils ecosystem.
  3. Combine djunits and djutils into one project, and make djunits a module of the djutils project. This can be done while keeping the org.djunits package name -- it will just be dependent on a djutils-parent pom file, and versioning will have to stay consistent with djutils (this causes an immediate problem, since djunits is at v 5.1.1 while djutils is at v 2.1.9. We should bump djutils to v 6.0.0 to avoid version clashes for djunits. Advantage: tight integration between djunits changes and its usage in djutils. Disadvantage: very different projects combined (djunits has also generators and a demo project -- what to do with them?), more complex project to maintain, versioning issues.

For now, I am thinking about a quick solution using (1) above, but should that also be the long-term solution?

Vector constructors: Allow a Map of sparse values as data instead of a SortedMap

Currently, the Vector and FloatVector classes take a SortedMap<Integer, Double> or SortedMap<Integer, Float> as argument for sparse data. There is, however, no need whatsoever to have this map sorted. Therefore, we can replace the SortedMap with Map in all Vector constructors and in the initialize method in the DoubleVectorData and FloatVectorData classes.

Add quetta (Q), ronna (R), ronto (r) and quecto (q) SI unit prefixes

In 2022, four new SI prefixes were introduced:

  • quetta (Q), 10^30
  • ronna (R), 10^27
  • ronto (r), 10^-27
  • quecto (q), 10^-30

These prefixes can be added to the SI units in djunits. The main class to do so is SIPrefixes. Don't forget that unit_en.properties and unit_nl.properties also have to be updated.

Update unit tests from JUnit 4 to JUnit 5

JUnit 5 has been the new standard for unit tests for quite a while now (since 2017). The big challenge for updating from version 4 to version 5 is that the order of the parameters in the various static assert statements such as assertEquals or assertNull has changed. Optional arguments such as the String message were at the front, where optional arguments are typically at the back. JUnit 5 puts these optional arguments at the back, leading to a massive number of changes in the unit test code. The package structure has also changed considerably.

JUnit 5 can be included as:

<dependency>
    <groupId>org.junit.jupiter</groupId>
    <artifactId>junit-jupiter-engine</artifactId>
    <version>5.10.0</version>
    <scope>test</scope>
</dependency>

Remove display unit storage in class and resource bundle

At the moment, all display units are stored in the quantity's unit class:

    public static final SpeedUnit KM_PER_HOUR = SI.deriveLinear(factorLD(LengthUnit.KILOMETER, 
            DurationUnit.HOUR), "km/h", "kilometer per hour", UnitSystem.SI_ACCEPTED, 
            "km/h", "km/h", "km/hr", "km/hour");

while the same information about the display units is also available in the language resource bundle:

Speed.km/h = km/h | kilometer per hour | km/hr | km/hour

For maintainability and flexibility uses, this information should be stored in only one place, preferably the resource bundle, since that information is now used to parse Locale-dependent input. This makes storage in the class superfluous.

Simplify class structure

The current class structure for types of Scalar, Vector and Matrix is tremendously complex, especially given that the code for these classes is generated. To show the complexity for, e.g., a Length:

  • Length extends AbstractDoubleScalarRelWithAbs<PositionUnit, Position, LengthUnit, Length>
  • AbstractDoubleScalarRelWithAbs extends AbstractDoubleScalarRel implements DoubleScalarInterface.RelWithAbs
  • AbstractDoubleScalarRel extends AbstractDoubleScalar implements DoubleScalarInterface.Rel
  • AbstractDoubleScalar extends AbstractScalar implements DoubleScalarInterface
  • AbstractScalar extends Number implements Scalar
  • Scalar extends Value, Comparable
  • Value extends ValueFunctions
  • ValueFunctions extends Serializable
  • DoubleScalarInterface.RelWithAbs extends DoubleScalarInterface, Scalar.RelWithAbs
  • DoubleScalarInterface extends Scalar
  • Scalar.RelWithAbs extends Scalar.Rel
  • Scalar.Rel extends Scalar, Relative
  • Relative
  • DoubleScalarInterface.Rel extends DoubleScalarInterface, Scalar.Rel

In other words, 14 classes and interfaces define the contract and implementation of the Length scalar. And I left out the tremendously complex generics like:

interface RelWithAbs<AU extends AbsoluteLinearUnit<AU, RU>, A extends DoubleScalarInterface.Abs<AU, A, RU, R>,
        RU extends Unit<RU>, R extends DoubleScalarInterface.RelWithAbs<AU, A, RU, R>>
        extends DoubleScalarInterface<RU, R>, Scalar.RelWithAbs<AU, A, RU, R>

With the default option in interfaces, and the possibility to define static functions in interfaces, several abstract classes can be removed from the hierarchy, without changing anything in the contract of a Scalar, Vector or Matrix such as the Length.

Remove maven-changes-plugin from pom file and site.xml

The maven-changes-plugin has not been updated since 2016. it is dependent on a number of very much outdated libraries wit lots of vulnerabilities that we rather do not install on our servers when compiling or testing a new version. Furthermore, changes are not kept in a separate changes.xml file anymore, but maintained using github issue management. The changes that are displayed are outdated and will not be updated in the file itself.

Therefore, the maven-changes-plugin is taken out from the pom file and site.xml files for now.

By commenting it out, it can be brought back later when the plugin is updated and potentially linked to github issue management.

Javadoc of Scalar has a few wrong entries

E.g.,

    /**
     * Test if this DoubleScalar is less than or equal to another DoubleScalar.
     * @param o T, a relative typed DoubleScalar; the right hand side operand of the comparison
     * @return boolean
     */
    boolean le(S o);

    /**
     * Test if this DoubleScalar is greater than or equal to a DoubleScalar.
     * @param o T, a relative typed DoubleScalar; the right hand side operand of the comparison
     * @return boolean; true if this is greater than or equal to other; false if this is not greater than or equal to other
     */
    boolean gt(S o);

    /**
     * Test if this DoubleScalar is greater than a DoubleScalar.
     * @param o T, a relative typed DoubleScalar; the right hand side operand of the comparison
     * @return boolean; true if this is greater than other; false if this is not greater than other
     */
    boolean ge(S o);

Same for gt0 and ge0: javadoc reversed.
other should read o.

Missing constants

The file value/vdouble/scalar/base/Constants.java defines a number of physical and mathematical constants.
Sorely missing are:
pi (but we do have tau)
e (Euler's constant)
Slighly less important (because it is quite easy to "construct"):
phi (The golden ratio; (1+sqrt(5)/2)

Suppress unit printing and parsing for Dimensionless

The Dimensionless scalar, vector and matrix print a unit called unit under certain circumstances, and 1 as a unit under other circumstances. unit is not a sensible indication of the unit for a dimensionless number. 1 is not a valid SI-unit. Probably the best solution is to completely suppress the unit printing and parsing for the Dimensionless scalar, vector and matrix.

Add constructors for UnitMatrix

The construction of Matrix instances with units is cumbersome, and not intuitive. Currently, constructing involves code like:

double[][] data = new double[1000][1000];
for (int i = 0; i < 1000; i++) {
  for (int j = 0; j < 1000; j++) {
    data[i][j] = 9 * i + 2 * j * 0.364;
  }
}
LengthMatrix lengthMatrix = new LengthMatrix(
  DoubleMatrixData.instantiate(data, IdentityScale.SCALE, StorageType.DENSE), LengthUnit.CENTIMETER);

The code could assume that the StorageType is DENSE, since we offer the data as an array. In case we would offer the data as a Map of indices to values, the code could assume that the StorageType is SPARSE. So, the last line should be replaced by:

LengthMatrix lengthMatrix = new LengthMatrix(data, LengthUnit.CENTIMETER);

This would be much more intuitive. The analogous implementation for Vector has already been completed successfully.

Locale handling should be improved

The use of Locale and DefaultLocale in djunits is not optimal. The following issues should (at least) be repaired:

  • use the standard Java names for the Locale files, such as en-US for the US locale and nl-NL for the Dutch locale.
  • always format the numbers according to the rules of the Locale.
  • remove the DefaultLocale class. Use the en_US locale files for prefixes when the used Locale does not have prefix files. Still format the numbers according to the used Locale.
  • add unit tests using different Locales, for reading (parsing) quantities as well as outputting (formatted) quantities.

Parsing of Scalar using a Locale is not working properly

In the LocaleDemo class, I added the following code: for testing:

        System.out.println("\nParsing UK");
    	Locale.setDefault(new Locale("en", "UK"));
    	Speed speed = Speed.valueOf("14.2 km/h");
        System.out.println(speed.toTextualString());
        System.out.println(speed.toDisplayString());
        System.out.println(speed);
    	
        System.out.println("\nParsing NL");
    	Locale.setDefault(new Locale("nl", "NL"));
    	speed = Speed.valueOf("14.2 km/u");
        System.out.println(speed.toTextualString());
        System.out.println(speed.toDisplayString());
        System.out.println(speed);

The output is:

Parsing UK
14.2 km/h
14.2 km/h
14.2000000 km/h

Parsing NL
Exception in thread "main" java.lang.IllegalArgumentException: Error parsing Speed from 14.2 km/u
	at org.djunits.value.vdouble.scalar.Speed.valueOf(Speed.java:196)
	at org.djunits.demo.examples.LocaleDemo.main(LocaleDemo.java:55)

Add constructors for UnitVector

The construction of Vector and Matrix instances with units is cumbersome, and not intuitive. Currently, constructing involves code like:

  double[] doubleValues = new double[] {0.2, 10.0, 5.7, 100.0, 15.0};
  DurationVector dva = DoubleVector.instantiate(doubleValues, DurationUnit.MINUTE, StorageType.DENSE);

More intuitive would be:

  double[] doubleValues = new double[] {0.2, 10.0, 5.7, 100.0, 15.0};
  DurationVector dva = new DurationVector(doubleValues, DurationUnit.MINUTE);

The code could assume that the StorageType is DENSE, since we offer the data as an array. In case we would offer the data as a Map of indices to values, the code could assume that the StorageType is SPARSE. This would create in total 20 constructors for each Vector (and a similar number for each Matrix).

Update maven site generation on server to site version 2.0.0

The site generation is outdated (version 1.6.0). The latest maven site generation version is 2.0.0, compatible with the maven site plugin version 4.0.

The site file has to be changed to:

<site xmlns="http://maven.apache.org/SITE/2.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/SITE/2.0.0 https://maven.apache.org/xsd/site-2.0.0.xsd"
  name="${project.artifactId} ${project.version}">

  <publishDate position="left" format="dd-MM-yyyy HH:mm" />

  <bannerLeft name="${project.name}" />
  <bannerRight name="${project.artifactId} ${project.version}" />

  <skin>
    <groupId>org.apache.maven.skins</groupId>
    <artifactId>maven-fluido-skin</artifactId>
    <version>2.0.0-M8</version>
  </skin>

  <body>
    <menu> ... </menu>
    <menu> ... </menu>
    <menu> ... </menu>
  </body>

</site>

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.