[
https://issues.apache.org/jira/browse/NUMBERS-193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17701265#comment-17701265
]
Alex Herbert commented on NUMBERS-193:
--------------------------------------
I think we are all agreed that we should test the current implementation and a
new immutable one written in the most efficient way. I think it was not clear
that I was suggesting a third implementation for the benchmark that just
creates new mutable instance for all operations. Note that I stated "could also
be done for a reference point". It is just a reference point. It does not have
to be done.
My interest in this third implementation is whether there is a performance
difference to adapting the current implementation to an OO API, and rewriting
the implementation to be immutable and OO. Both will have to create new objects
for each operation. The later should create new objects more efficiently. The
objects will still have to be garbage collected at some point and this may turn
out to be the major overhead.
> 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
> Reporter: 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)
