Source code
package com.google.common.math;
import static com.google.common.base.Preconditions.checkArgument;
import static java.lang.Double.MAX_EXPONENT;
import static java.lang.Double.MIN_EXPONENT;
import static java.lang.Double.POSITIVE_INFINITY;
import static java.lang.Double.doubleToRawLongBits;
import static java.lang.Double.isNaN;
import static java.lang.Double.longBitsToDouble;
import static java.lang.Math.getExponent;
import static java.lang.Math.max;
import com.google.common.annotations.GwtIncompatible;
import com.google.common.annotations.VisibleForTesting;
import java.math.BigInteger;
/**
* Utilities for {@code double} primitives.
*
* @author Louis Wasserman
*/
@GwtIncompatible
final class DoubleUtils {
private DoubleUtils() {}
// The mask for the significand, according to the {@link
// Double#doubleToRawLongBits(double)} spec.
static final long SIGNIFICAND_MASK = 0x000fffffffffffffL;
// The mask for the exponent, according to the {@link
// Double#doubleToRawLongBits(double)} spec.
static final long EXPONENT_MASK = 0x7ff0000000000000L;
// The mask for the sign, according to the {@link
// Double#doubleToRawLongBits(double)} spec.
static final long SIGN_MASK = 0x8000000000000000L;
static final int SIGNIFICAND_BITS = 52;
static final int EXPONENT_BIAS = 1023;
/** The implicit 1 bit that is omitted in significands of normal doubles. */
static final long IMPLICIT_BIT = SIGNIFICAND_MASK + 1;
static long getSignificand(double d) {
checkArgument(isFinite(d), "not a normal value");
long bits = doubleToRawLongBits(d);
bits &= SIGNIFICAND_MASK;
return ((getExponent(d)) == MIN_EXPONENT - 1) ? bits << 1 : bits | IMPLICIT_BIT;
}
static boolean isFinite(double d) {
return getExponent(d) <= MAX_EXPONENT;
}
static boolean isNormal(double d) {
return getExponent(d) >= MIN_EXPONENT;
}
/*
* Returns x scaled by a power of 2 such that it is in the range [1, 2). Assumes x is positive,
* normal, and finite.
*/
static double scaleNormalize(double x) {
return longBitsToDouble((doubleToRawLongBits(x) & SIGNIFICAND_MASK) | ONE_BITS);
}
static double bigToDouble(BigInteger x) {
// This is an extremely fast implementation of BigInteger.doubleValue(). JDK patch pending.
BigInteger absX = x.abs();
int exponent = absX.bitLength() - 1;
// exponent == floor(log2(abs(x)))
if (exponent < Long.SIZE - 1) {
return x.longValue();
} else if (exponent > MAX_EXPONENT) {
return x.signum() * POSITIVE_INFINITY;
}
/*
* We need the top SIGNIFICAND_BITS + 1 bits, including the "implicit" one bit. To make rounding
* easier, we pick out the top SIGNIFICAND_BITS + 2 bits, so we have one to help us round up or
* down. twiceSignifFloor will contain the top SIGNIFICAND_BITS + 2 bits, and signifFloor the
* top SIGNIFICAND_BITS + 1.
*
* It helps to consider the real number signif = absX * 2^(SIGNIFICAND_BITS - exponent).
*/
int shift = exponent - SIGNIFICAND_BITS - 1;
long twiceSignifFloor = absX.shiftRight(shift).longValue();
long signifFloor = twiceSignifFloor >> 1;
signifFloor &= SIGNIFICAND_MASK; // remove the implied bit
/*
* We round up if either the fractional part of signif is strictly greater than 0.5 (which is
* true if the 0.5 bit is set and any lower bit is set), or if the fractional part of signif is
* >= 0.5 and signifFloor is odd (which is true if both the 0.5 bit and the 1 bit are set).
*/
boolean increment =
(twiceSignifFloor & 1) != 0 && ((signifFloor & 1) != 0 || absX.getLowestSetBit() < shift);
long bits = (long) (exponent + EXPONENT_BIAS) << SIGNIFICAND_BITS;
bits += (increment ? signifFloor + 1 : signifFloor);
/*
* If signifRounded == 2^53, we'd need to set all of the significand bits to zero and add 1 to
* the exponent. This is exactly the behavior we get from just adding signifRounded to bits
* directly. If the exponent is MAX_DOUBLE_EXPONENT, we round up (correctly) to
* Double.POSITIVE_INFINITY.
*/
bits |= x.signum() & SIGN_MASK;
return longBitsToDouble(bits);
}
/** Returns its argument if it is non-negative, zero if it is negative. */
static double ensureNonNegative(double value) {
checkArgument(!isNaN(value));
return max(value, 0.0);
}
@VisibleForTesting static final long ONE_BITS = 0x3ff0000000000000L;
}
Run 1
The code is generally well-structured and readable, with clear constants, descriptive method names, and helpful comments explaining complex bit manipulation logic. However, readability is hindered by the heavy reliance on low-level bit operations without introductory context, and some methods (notably `bigToDouble`) are dense and require significant domain knowledge to parse. The code length is justified by the complexity of the operations, but action granularity sometimes suffers, as multiple related operations are chained into single statements (e.g., `return longBitsToDouble((doubleToRawLongBits(x) & SIGNIFICAND_MASK) | ONE_BITS);`). Reading flow is mostly logical, but some explanatory comments are lengthy and could be condensed. Overall, it's readable for an experienced audience but not immediately accessible to a generalist.
Run 2
The code is generally well-structured and readable. Constants are clearly named and documented, methods are short and focused, and comments explain non-obvious algorithms. The bit manipulation logic in bigToDouble is inherently complex, but the comments help. Minor issues: inconsistent use of blank lines after method declarations, some long lines, and the magic number `ONE_BITS` is defined at the bottom without immediate context. The reading flow could be slightly improved by grouping related methods together. Overall, it's understandable for experienced developers familiar with IEEE 754, but the domain complexity prevents a higher score.
Run 3
The code is generally readable with clear structure, flat nesting, and logical organization. Constants are well-documented with comments explaining their purpose based on the IEEE 754 double format. Method names are descriptive and intent-revealing. The comments for complex operations like bigToDouble and scaleNormalize provide helpful context and rationale. Action granularity is mostly one operation per line. However, readability is slightly reduced by the heavy reliance on bit manipulation which requires domain knowledge of double representation. Some lines with bitwise operations and shifting are inherently dense. The bigToDouble method has a moderately complex section with several bit operations that could benefit from further decomposition or additional inline comments. Despite this, the code maintains good reading flow and avoids unnecessary nesting.
Run 1
Code Structure: Well organized into a focused utility class with named constants and small methods, though ONE_BITS would fit better alongside the other constants. Nesting: Minimal; early returns keep the main conversion method flat. Clarity of intent: Descriptive method names and detailed comments explain the bit manipulation and rounding, but abbreviated variables and dense expressions require IEEE 754 knowledge. Code length: Mostly concise; the longer conversion method and its explanatory comments are justified by the algorithm's complexity. Action granularity: Generally one operation per line, with a few compound expressions combining several bitwise or logical operations. Reading flow: Natural progression from constants to helpers and conversion logic; occasional unnecessary parentheses, blank lines, and the trailing constant slightly interrupt consistency.
Run 2
Code Structure: Well-organized utility class with named constants and focused methods; ONE_BITS would fit more naturally beside the other constants. Nesting: Shallow conditionals and early returns keep control flow straightforward. Clarity of intent: Descriptive names and detailed comments explain floating-point representation and rounding, although dense bitwise expressions require specialist knowledge. Code length: Mostly concise; the longer bigToDouble method and its comments are justified by algorithmic complexity. Action granularity: Statements generally perform one action each, with intermediate variables separating calculation steps; some compound expressions remain demanding. Reading flow: Methods progress naturally from validation through computation to return values. Minor formatting inconsistencies, redundant parentheses, and an imprecise validation message slightly reduce readability.
Run 3
Code Structure: Well-organized utility class with named constants and focused methods; ONE_BITS would fit more naturally beside the other constants. Nesting: Minimal nesting, with straightforward early returns. Clarity of intent: Descriptive names and detailed comments explain otherwise difficult IEEE-754 operations, although dense bit manipulation and the 'not a normal value' message for a finiteness check introduce ambiguity. Code length: Appropriately concise for the numerical complexity; longer comments provide useful context rather than unnecessary bulk. Action granularity: Most lines perform one clear action, though the rounding condition combines several operations and requires careful reading. Reading flow: Generally natural, progressing from constants through small helpers to conversion logic, but complex expressions, occasional extra parentheses, and inconsistent blank lines slightly interrupt the flow.