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 a(double a) {
checkArgument(b(a), "not a normal value");
int b = getExponent(a);
long c = doubleToRawLongBits(a);
c &= SIGNIFICAND_MASK;
return (b == MIN_EXPONENT - 1) ? c << 1 : c | IMPLICIT_BIT;
}
static boolean b(double d) {
return getExponent(d) <= MAX_EXPONENT;
}
static boolean c(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 d(double e) {
long f = doubleToRawLongBits(e) & SIGNIFICAND_MASK;
return longBitsToDouble(f | ONE_BITS);
}
static double e(BigInteger g) {
// This is an extremely fast implementation of BigInteger.doubleValue(). JDK patch pending.
BigInteger h = g.abs();
int i = h.bitLength() - 1;
// exponent == floor(log2(abs(x)))
if (i < Long.SIZE - 1) {
return g.longValue();
} else if (i > MAX_EXPONENT) {
return g.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 j = i - SIGNIFICAND_BITS - 1;
long k = h.shiftRight(j).longValue();
long l = k >> 1;
l &= 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 m =
(k & 1) != 0 && ((l & 1) != 0 || h.getLowestSetBit() < j);
long n = m ? l + 1 : l;
long o = (long) (i + EXPONENT_BIAS) << SIGNIFICAND_BITS;
o += n;
/*
* 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.
*/
o |= g.signum() & SIGN_MASK;
return longBitsToDouble(o);
}
/** Returns its argument if it is non-negative, zero if it is negative. */
static double f(double p) {
checkArgument(!isNaN(p));
return max(p, 0.0);
}
@VisibleForTesting static final long ONE_BITS = 0x3ff0000000000000L;
}
Run 1
The code is highly obfuscated due to single-letter method and variable names (a, b, c, d, e, f, h, i, j, k, l, m, n, o, p), making it very difficult to understand intent at a glance. The structure is logical at a high level, but the lack of descriptive identifiers destroys clarity and reading flow. Nesting is mostly flat, which is good, but action granularity suffers in the complex e(BigInteger) method where bitwise operations are chained densely. The overall length is overly verbose due to comments that try to compensate for unclear naming, but with better names the code could be much shorter and self-documenting. The central algorithm in method e is especially hard to follow due to terse variables. This appears to be a deliberately minified version, which severely impacts readability despite being functionally correct. The score reflects moderate structure but critical failings in naming clarity and expressiveness.
Run 2
The code is structurally organized with clear sections for constants and helper methods, but readability is severely hampered by cryptic single-letter method and variable names (e.g., 'a', 'b', 'c', 'd', 'e', 'f'). This obscures intent and forces the reader to infer purpose from context. Nesting is generally shallow, and action granularity is mostly reasonable, with one operation per line in key sections. However, the dense bit-manipulation logic in method 'e' is hard to follow despite comments, due to unclear naming and complex shifts. The reading flow is disrupted by the need to constantly map abstract names to their actual roles. While comments explain some algorithms, the lack of meaningful identifiers makes the code feel more like obfuscated or minified code than maintainable source.
Run 3
The code has severe readability issues due to obfuscated naming. Methods are named a(), b(), c(), etc., and parameters use single letters like a, b, c, d, e, f, g, h, i, j, k, l, m, n, o, p. This makes the intent completely ambiguous without deep analysis. The structure is otherwise organized and the comments are excellent, explaining complex bit manipulations and rounding logic. However, the naming completely undermines clarity of intent and reading flow. Nesting is reasonable, and code length is appropriate for the complex operations, but the lack of meaningful identifiers makes it read like decompiled code. Action granularity is mostly fine. The comments partially compensate, but the code remains very hard to follow because you cannot map the explanation to the obfuscated variable names naturally.
Run 1
Code Structure: Constants and focused utility methods provide logical organization, though ONE_BITS is separated from related constants. Nesting: Mostly flat, with simple conditionals and early returns. Clarity of intent: Descriptive constants and detailed numerical comments help, but single-letter method and variable names severely obscure purpose. Several comments reference descriptive identifiers absent from the code, forcing readers to reconstruct their mappings. Code length: The implementation is reasonably concise; lengthy comments explain genuinely complex bit manipulation rather than unnecessary code. Action granularity: Most lines perform one action, although compound bitwise and rounding expressions require careful parsing. Reading flow: Consistent formatting and small methods support navigation, but opaque names, dense arithmetic, and mismatched comment terminology repeatedly interrupt comprehension.
Run 2
Code Structure: Constants and focused utility methods provide logical organization, although ONE_BITS is separated from related constants. Nesting: Mostly flat, with simple conditionals and early returns. Clarity of intent: Descriptive constants and detailed comments help, but single-letter method and variable names obscure purpose, especially in the BigInteger conversion. Comments reference meaningful variable names absent from the code, increasing interpretation effort. Code length: Implementation is reasonably concise; lengthy comments are justified by complex floating-point rounding logic. Action granularity: Statements generally perform one action per line, although bitwise expressions combine several conceptual operations. Reading flow: Consistent formatting and sequential conversion steps support reading, but cryptic identifiers and comment-to-code mismatches repeatedly interrupt comprehension.
Run 3
Code Structure: Constants and focused utility methods provide logical organization, though ONE_BITS appears after the methods. Nesting: Shallow conditionals and early returns keep complexity manageable. Clarity of intent: Descriptive constants and detailed comments explain floating-point operations, but single-letter method and variable names severely obscure purpose; some comments reference descriptive names absent from the code. Code length: The implementation is reasonably concise, with lengthy comments justified by intricate rounding logic. Action granularity: Most lines perform one operation, although compound bitwise expressions require careful interpretation. Reading flow: Consistent formatting and sequential computation help, but opaque identifiers, dense bit manipulation, and comments disconnected from actual variable names force frequent mental reconstruction.