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"); int exponent = getExponent(d);
long bits = doubleToRawLongBits(d);
bits &= SIGNIFICAND_MASK; return (exponent == 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) { long significand = doubleToRawLongBits(x) & SIGNIFICAND_MASK;
return longBitsToDouble(significand | 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 signifRounded = increment ? signifFloor + 1 : signifFloor; long bits = (long) (exponent + EXPONENT_BIAS) << SIGNIFICAND_BITS;
bits += signifRounded; /*
* 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 functionally sophisticated but fails readability standards. Structure is impaired by inconsistent indentation and compressed lines combining imports and statements. Nesting is acceptable but formatting hides it, e.g., collapsed one-line methods. Clarity of intent is undermined by terse comments and magic constants; the long method `bigToDouble` is particularly dense, mixing bit manipulation, shifting, and rounding logic in a block that is hard to follow. Code length is not the issue, but several lines attempt multiple actions, violating the 'one action per line' rule. Reading flow is disorganized due to inconsistent bracing, alignment, and placement of the `ONE_BITS` field at the end. While the algorithms may be correct, the presentation makes the code nearly unreadable for a newcomer. A clean-up with proper formatting, line breaks, and explanatory comments would raise the score substantially.
Run 2
The code is highly unreadable due to severe formatting issues. Multiple statements are crammed onto single lines, making it difficult to distinguish where one logical operation ends and another begins. The nesting is not deeply indented, but the lack of line breaks creates a tangled structure. Several methods are compressed together, such as getSignificand and bigToDouble, which have multiple actions on one line. Comments are interspersed with code and sometimes split awkwardly, disrupting the reading flow. The intent is present in comments but obscured by poor layout. Code length is not excessive, but the formatting makes it unnecessarily dense. Action granularity is poor: many lines contain two or more operations, sometimes with control flow mixed in. Overall, the reader must expend extra effort to parse the code, significantly reducing readability despite the underlying logic being reasonably straightforward.
Run 3
The code has severe readability problems. The structure is disorganized: constants are scattered, methods are intermixed without logical grouping, and there is inconsistent indentation and spacing. Multiple statements are crammed onto single lines, making it difficult to parse individual operations. While some comments explain tricky bit-manipulation logic, they are inconsistently placed and sometimes interrupt the flow. Method names generally convey intent, but the dense, compressed formatting obscures the underlying algorithms. The bigToDouble method is especially hard to follow due to its length, deep arithmetic expressions, and lack of visual breaks between logical steps. Nesting is not excessive, but the overall lack of whitespace and structure makes the code feel tangled and difficult to scan.
Run 1
Code Structure: Related utilities and named constants provide logical organization, but compressed method boundaries obscure it. Nesting: Shallow conditionals and early returns keep control flow simple. Clarity of intent: Descriptive names and detailed comments explain floating-point manipulation and rounding, although dense bitwise expressions require careful reading. Code length: Implementation is reasonably concise; explanatory comments are useful rather than unnecessary. Action granularity: Multiple imports, declarations, assignments, and returns share lines, making individual actions harder to distinguish. Reading flow: Inconsistent spacing, inline annotations, crowded braces, and comments attached to method endings interrupt otherwise coherent progression. The underlying design is readable, but poor formatting significantly reduces scanability.
Run 2
Code Structure: Cohesive utility methods and named constants provide logical organization, but compressed method boundaries obscure it. Nesting: Shallow conditionals and early returns keep control flow easy to follow. Clarity of intent: Descriptive names and detailed comments explain the bit manipulation and rounding logic, although the numerical operations require careful reading. Code length: The implementation is reasonably concise; extensive comments are justified by algorithmic complexity. Action granularity: Multiple imports, declarations, assignments, returns, and even method definitions share lines, significantly reducing readability. Reading flow: Inconsistent spacing, indentation, and comments attached to closing braces interrupt an otherwise natural progression from constants to helper methods and conversion logic.
Run 3
Code Structure: Constants and focused utility methods provide logical organization, but compressed method boundaries obscure it. Nesting: Mostly flat, with shallow conditionals and early returns. Clarity of intent: Descriptive names and detailed comments explain complex floating-point operations, although bit manipulation requires specialist knowledge. Code length: The implementation is reasonably concise; explanatory comments are useful rather than excessive. Action granularity: Multiple imports, declarations, assignments, and returns share lines, making individual steps harder to distinguish. Reading flow: Inconsistent indentation, inline comments, and adjacent method definitions interrupt otherwise logical progression. Overall, sound organization and documentation are undermined by poor formatting.