[
https://issues.apache.org/jira/browse/NUMBERS-155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17333293#comment-17333293
]
Alex Herbert commented on NUMBERS-155:
--------------------------------------
Currently the {{o.a.c.numbers.arrays.ExtendedPrecision}} class is package
private and has some package private methods exposed for unit testing. The two
methods of interest for a public API are:
{code:java}
/**
* Compute the low part of the double length number {@code (z,zz)} for the
exact
* product of {@code x} and {@code y}. This is equivalent to computing a
{@code double}
* containing the magnitude of the rounding error when converting the exact
106-bit
* significand of the multiplication result to a 53-bit significand.
*
* @param x First factor.
* @param y Second factor.
* @param xy Product of the factors (x * y).
* @return the low part of the product double length number
* @see #highPartUnscaled(double)
*/
static double productLow(double x, double y, double xy);
/**
* Compute the round-off from the sum of two numbers {@code a} and {@code
b} using
* Knuth's two-sum algorithm. The values are not required to be ordered by
magnitude.
* The standard precision sum must be provided.
*
* @param a First part of sum.
* @param b Second part of sum.
* @param sum Sum of the parts (a + b).
* @return <code>(b - (sum - (sum - b))) + (a - (sum - b))</code>
*/
static double twoSumLow(double a, double b, double sum) {
{code}
Both of these methods assume that the user has already computed either the
product or the sum of the two input arguments. If they are not called with this
value then the methods will compute an incorrect result. Two options for public
use are to remove the input argument and just compute it:
{code:java}
public static double productLow(double x, double y) {
return productLow(x, y, x * y);
}
{code}
However in most cases you would not require the low (extended precision) part
if you did not also require the high (standard precision) part. The other
option is therefore to provide a paired result. There is an example of this in
the source material in the JMH examples package in class
{{o.a.c.numbers.examples.jmh.arrays.DoublePrecision}}:
{code:java}
/**
* Represents a floating-point number with twice the precision of a {@code
double}.
*/
static final class Quad {
// This is treated as a simple struct.
/** The high part of the number. */
double hi;
/** The low part of the number. */
double lo;
}
/**
* Multiply the values {@code x} and {@code y} into a double-precision
result {@code c}.
*
* @param x First value
* @param y Second value
* @param c Result
*/
static void multiply(double x, double y, Quad c);
{code}
There are two implementations that do the same but one adds scaling to protect
against intermediate over/underflow. The methods are tested using for example:
{code:java}
cd commons-numbers-examples/examples-jmh
mvn package -Pexamples-jmh
java -jar target/examples-jmh.jar DoubleSplitPerformance.productLow -p
size=10000 -p exp=600 -p edge=0.999
{code}
This tests multiplication of 10000 pairs of two numbers, each of which has an
exponent of 600 with a probability of 0.001, and exponent of 1 otherwise (i.e.
some product pairs will overflow).
> About modules "arrays" and "rootfinder"
> ---------------------------------------
>
> Key: NUMBERS-155
> URL: https://issues.apache.org/jira/browse/NUMBERS-155
> Project: Commons Numbers
> Issue Type: Task
> Components: arrays, core
> Affects Versions: 1.0-beta1
> Reporter: Gilles Sadowski
> Priority: Major
> Labels: refactoring
> Fix For: 1.0
>
>
> Shouldn't some functionality currently in module {{commons-numbers-arrays}}
> be moved to {{commons-number-core}}?
> Rationale is that the utilities focus on extended precision of some
> computations (on numbers that happen to be stored in an array).
> Wouldn't the Brent solver (in module {{commons-numbers-rootfinder}}) benefit
> from a version based on the new {{ExtendedPrecision}} class?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
