[
https://issues.apache.org/jira/browse/NUMBERS-193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17751963#comment-17751963
]
Gilles Sadowski commented on NUMBERS-193:
-----------------------------------------
{quote}
* Adding the DD class in its current state to a new module
{quote}
It seems that it belongs to the {{core}} module.
{quote}
* Exposing the accurate versions of arithmetic operators in a helper class. A
use case may exist that I have not considered and these methods are still
reasonably fast (compared to BigDecimal) and are mostly double-double exact (or
within 1 rounding error).
{quote}
If no use-case is currently known, I'd delay the delay the decision to make
those part of the "public" API.
{quote}
* Any use of DD as a field would require a wrapper class to implement the
required NativeOperators interface
{quote}
As you noted, it would be fixed with the class being in {{core}}.
{quote}
* Updating downstream projects to use DD when possible
{quote}
+1
{quote}
* Possibly extending the current public API to expose more raw building block
methods for extended floating point arithmetic (fast-two-sum; two-sum;
two-product).
{quote}
Are these lower-level than {{DD}}?
IOW: What's the added value wrt {{DD}}?
{quote}
* Possibly adding a triple-double and/or quad double and/or arbitrary length
implementation. I currently have no use case for these so it would be an
academic exercise. The possible existence of e.g. a quad-double does possibly
impact package location and names for the parts of the number by allowing
standardising across implementations in a single package location.
{quote}
I imagine that the relative benefits of adding more components would not
increase as dramatically as with {{DD}}.
The question is indeed whether there are use cases where
# {{BigDecimal}} would be too slow, and
# users in those domains would be interested in a Java implementation.
{quote}
* Putting DD in numbers core
{quote}
+1
{quote}
* Names for factory constructor methods, i.e. of and from
{quote}
Should all be public?
An unsuspecting user like me might not understand why do
{code}
double a = ...
double b = ...
DD v = DD.ofSum(a, b);
{code}
instead of
{code}
DD v = DD.of(a).add(DD.of(b));
{code}
{quote}
* Names for the parts of the number: (x, xx) vs (x0, x1) vs (hi, lo) vs other
{quote}
(hi, lo) is self-documenting, and less error-prone.
Also, for searching within the code, it will be slightly easier that the two
fields have completely different names.
{quote}
* Hiding the accurate arithmetic methods
* Hiding the scaled power method (but is required for Statistics inference)
* Hiding the accurate scaled power method (this would require it remaining in
Statistics inference package)
{quote}
As argued elsewhere, I'd strongly prefer that quite non-obvious algorithms are
implemented in a single place.
> Add support for extended precision floating-point numbers
> ---------------------------------------------------------
>
> Key: NUMBERS-193
> URL: https://issues.apache.org/jira/browse/NUMBERS-193
> Project: Commons Numbers
> Issue Type: New Feature
> Components: ext
> Reporter: Alex Herbert
> Assignee: Alex Herbert
> Priority: Major
> Labels: full-time, gsoc2023, part-time
>
> Add implementations of extended precision floating point numbers.
> An extended precision floating point number is a series of floating-point
> numbers that are non-overlapping such that:
> {noformat}
> double-double (a, b):
> |a| > |b|
> a == a + b{noformat}
> Common representations are double-double and quad-double (see for example
> David Bailey's paper on a quad-double library:
> [QD|https://www.davidhbailey.com/dhbpapers/qd.pdf]).
> Many computations in the Commons Numbers and Statistics libraries use
> extended precision computations where the accumulated error of a double would
> lead to complete cancellation of all significant bits; or create intermediate
> overflow of integer values.
> This project would formalise the code underlying these use cases with a
> generic library applicable for use in the case where the result is expected
> to be a finite value and using Java's BigDecimal and/or BigInteger negatively
> impacts performance.
> An example would be the average of long values where the intermediate sum
> overflows or the conversion to a double loses bits:
> {code:java}
> long[] values = {Long.MAX_VALUE, Long.MAX_VALUE};
> System.out.println(Arrays.stream(values).average().getAsDouble());
> System.out.println(Arrays.stream(values).mapToObj(BigDecimal::valueOf)
> .reduce(BigDecimal.ZERO, BigDecimal::add)
> .divide(BigDecimal.valueOf(values.length)).doubleValue());
> long[] values2 = {Long.MAX_VALUE, Long.MIN_VALUE};
> System.out.println(Arrays.stream(values2).asDoubleStream().average().getAsDouble());
> System.out.println(Arrays.stream(values2).mapToObj(BigDecimal::valueOf)
> .reduce(BigDecimal.ZERO, BigDecimal::add)
> .divide(BigDecimal.valueOf(values2.length)).doubleValue());
> {code}
> Outputs:
> {noformat}
> -1.0
> 9.223372036854776E18
> 0.0
> -0.5{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
