[
https://issues.apache.org/jira/browse/NUMBERS-193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17752081#comment-17752081
]
Alex Herbert commented on NUMBERS-193:
--------------------------------------
I will rearrange the code to move it to numbers core.
{quote}Accurate methods - delay the delay the decision to make those part of
the "public" API.
{quote}
I will put these in a class for testing so they are preserved for the future.
{quote}Names for factory constructor methods, i.e. of and from - Should all be
public?
{quote}
{color:#172b4d}Yes. I'll add some more information in the class Javadoc on how
to create a DD number. It is far more efficient, and more logical from the
literature, to create them from a pair of doubles as a single operation than to
create two DD numbers and then combine them. The DD is the result of the
standard double operation, plus a representation of the round-off lost in the
operation by rounding.{color}
{color:#172b4d}If you create the DD numbers from a double before the operation
then their round-off is zero and the computation will waste ~80% of its
execution doing nothing by computing and moving around zeros. For add, subtract
and multiply the result will be the same. For divide the result may be less
accurate when performed as a DD operation.{color}
{color:#172b4d}A section in the user guide will also help with the expected
usage.{color}
{quote}Re: fast-two-sum; two-sum; two-product
Are these lower-level than {{{}DD{}}}?
IOW: What's the added value wrt {{{}DD{}}}?
{quote}
Low level - Yes they are. Every paper in the literature introduces
fast-two-sum; two-sum and two-product as building blocks for their algorithms.
The two-sum and two-product are provided by using the factory constructors
ofSum and ofProduct. But the code does not currently expose fast-two-sum. It is
a user beware function where the arguments must be used in magnitude order (a +
b where |a| > |b|).
When directly working with double values it useful to have these methods coded
to accept the standard double result and compute the round-off as a double. For
now we can leave them hidden at the package level. As pointed out with the
accurate methods, do not make them public unless a use case arises.
{quote}Names for the parts of the number: (x, xx) vs (x0, x1) vs (hi, lo) vs
other
(hi, lo) is self-documenting, and less error-prone.
{quote}
I have updated the accessors to use hi() and lo(). Internally the class still
utilises (x, xx) and documentation refers to the number using the tuple format
(x, xx). The use of a tuple in internal working allows raw DD numbers expressed
as doubles to be referred to as paired variables: (x, xx), (y, yy), (z, zz).
The use of hi and lo for the properties does make the code more readable when
using a DD object as the dot notation acts as a substitute for a subscript
(x{~}hi{~}, x{~}lo{~}):
{code:java}
DD x = ...
x.hi()
x.lo(){code}
I updated the method ldexp to be named scalb. This will be more familiar to
Java users.
PR for review: [PR 137|https://github.com/apache/commons-numbers/pull/137]
> 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)
