[
https://issues.apache.org/jira/browse/SIS-568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-568:
------------------------------------
Issue Type: Improvement (was: Task)
> Simplify matrix internal and double-double arithmetic
> -----------------------------------------------------
>
> Key: SIS-568
> URL: https://issues.apache.org/jira/browse/SIS-568
> Project: Spatial Information Systems
> Issue Type: Improvement
> Components: Referencing
> Affects Versions: 1.3
> Reporter: Martin Desruisseaux
> Assignee: Martin Desruisseaux
> Priority: Major
> Fix For: 1.4
>
>
> Apache SIS uses double-double arithmetic internally for increasing the
> chances to detect when concatenation of coordinate operations cancel each
> other or when the operation can be simplified/optimized. For example with
> standard {{double}} arithmetic, (A/B)*B is not always equal to A. The common
> approach is to use a small tolerance factor, but the threshold is very
> difficult to choose. For example datum shifts can be small enough for being
> confused with a threshold.
> In addition to double-double arithmetic, Apache SIS uses its own matrix
> implementation because it needs to handle NaN values in a different way than
> what common packages do. SIS also handles non-square matrices in a different
> way, knowing that they appear when the operation changes the number of CRS
> dimensions. Finally Apache SIS matrix implementation is designed for working
> with above-cited double-double arithmetic.
> Performance concern has lead to a complicated implementation in all Apache
> SIS versions up to 1.3. {{DoubleDouble}} is mutable for allowing codes to
> recycle existing instances, which make expressions non-fluent.
> {{GeneralMatrix}} stores ({_}value{_} + {_}error{_}) components of
> {{DoubleDouble}} while {{MatrixN}} do not, which forces SIS code to worry
> about whether a matrix uses double-double arithmetic or not. In practice, we
> found (relatively minor) bugs in SIS 1.3 caused by double-double precision
> lost between matrix implementations.
> We need to simplify the situation. It can be done with the following steps:
> * Make {{DoubleDouble}} immutable. The original performance concern may be
> obsolete thanks to compiler optimizations, and will probably become yet more
> obsolete with _value object_ to be provided in a future Java version.
> * Replace all {{DoubleDouble}} usages by fluent expressions. This is made
> possible by the above point.
> * Reduce {{DoubleDouble}} usage where we do not expect the extra accuracy to
> be significant.
> * Remove all explicit handling of double-double in {{{}GeneralMatrix{}}}.
> Instead, stores the values as {{{}Number{}}}. The possibly increased memory
> consumption is not a concern because this matrix size rarely exceed 5×5.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
