[ 
https://issues.apache.org/jira/browse/NUMBERS-193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17701254#comment-17701254
 ] 

Sentaro Onizuka commented on NUMBERS-193:
-----------------------------------------

{quote}Yes, but my point was that the benchmark could be biased if the class is 
mutable but does not takes advantage of it, and creates new instances instead 
(in effect taking the worst of both worlds). The comparison should be between
 * mutability and not creating instances
 * immutability and (necessarily) creating new instances{quote}
I understand that, and my unclear point about the benchmark has been cleared up.

{quote}
 In effect, DD.create() will return an "empty" instance, so there must be 
setters, invoking them will take time...
All this may not be equivalent to a factory method that calls the constructor 
of an immutable instance...
{quote}
This bothers me as well.

> 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)

Reply via email to