Sample

int-aa151de86d2a-I06

Invert eligible conditions and exchange their branches

Matched original source

Lines119

Scores

MethodScoreScale
Posnett00–1; higher is more readable
Scalabrino0.7790–1; higher is more readable
Dorn0.3520–1; higher is more readable
Mi0.60–1; higher is more readable
LLOC41Logical lines; fewer is more readable
DeepSeek V4 Pro12.330–20; mean of three runs
GPT-6.1 Sol15.330–20; mean of three runs
BTTF0.5750–1; higher is more readable

Views

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))) { if (exponent > MAX_EXPONENT) { return x.signum() * POSITIVE_INFINITY; } } else { return x.longValue(); } /* * 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; }

Loading feature diagnosis…

Source regions

Feature contributions

Feature contributions

FeatureValueContribution
(log-odds)
Halstead volumeHow much symbolic information the code contains. It combines the total number of operators and values with the number of distinct ones.3573.863−117.937
Source linesThe number of non-empty source lines.119+47.6
Byte entropyHow varied the bytes in the source text are. Repeated bytes give a lower value; a more even mixture gives a higher value.5.125−7.687

Intercept 8.87 + feature contributions = -69.155 (log-odds).
Score = sigmoid(-69.155) = 0.

Score0.779

Feature contributions

FeatureValueContribution
(log-odds)
Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code.119−3.177
Indentation frequencyHow rapidly indentation changes from line to line.87+2.272
Number layout frequencyHow rapidly the number of numeric values per line changes through the code.86−1.553
Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom.118.911+1.252
Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right.95.042+0.729
Identifier layout (horizontal)How rapidly the visual pattern of identifier characters changes from left to right. It measures spatial frequency, not the meaning of the names.99.983−0.57
Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *.0.059+0.364

Intercept 0.07 + feature contributions = -0.612 (log-odds).
Score = sigmoid(-0.612) = 0.352.

Score0.6
Score41
Run 1

The code is generally structured with clear sections for constants and methods, and comments explain non-obvious logic, especially in bigToDouble. However, several issues reduce readability. The if-else in bigToDouble is awkwardly nested and poorly structured with an empty else block, breaking reading flow and clarity of intent. Variable names like 'signifFloor', 'twiceSignifFloor', and expressions like 'absX.getLowestSetBit() < shift' require significant domain knowledge. The method getSignificand relies on understanding exponent edge cases without inline explanation. While each line mostly performs one action, several lines are dense with multiple operations. The code is concise for its complexity but sometimes at the expense of obviousness. The overall action granularity is mostly good, with comments delineating steps, but the tangled conditional and terse naming prevent a higher score.

Run 2

The code is generally well-structured with clear sections for constants, helper methods, and a complex conversion routine. However, readability is hampered by several factors. The 'bigToDouble' method contains deeply nested if statements with non-obvious logic, violating the nesting and clarity criteria. The method is also quite long and involves bit manipulation that, while documented, remains hard to follow. Some actions are combined into single lines (e.g., 'long bits = (long) (exponent + EXPONENT_BIAS) << SIGNIFICAND_BITS;'), reducing clarity. The reading flow is disrupted by the non-linear logic in 'bigToDouble'. Overall, while the code uses descriptive names and has useful comments, its complexity in key methods makes it moderately readable at best.

Run 3

The code is a utility class with clear constants and method naming, but readability suffers due to several issues. The `bigToDouble` method contains a confusing conditional structure with awkwardly nested braces (`if (!((exponent < Long.SIZE - 1))) { if (exponent > MAX_EXPONENT) {...} } else {...}`), making the branching logic hard to follow. Bit manipulation operations are dense and require deep domain knowledge, with multiple actions packed per line. Comments explain complex sections but are lengthy. The overall structure is logical, but the heavy use of magic numbers and bitwise operations reduces clarity for typical readers. Nesting is mostly shallow except for the problematic `bigToDouble` method. Action granularity varies, with some lines combining multiple operations. The reading flow is disrupted by the convoluted early-return logic. The code prioritizes performance over readability, making it challenging to quickly grasp the intent without careful study.

Run 1

Code Structure: Cohesive utility class with well-separated methods and descriptive constants. Nesting: Mostly flat, but bigToDouble contains an awkward nested conditional with redundant negation and parentheses. Clarity of intent: Method names and detailed comments explain the numerical operations, although bit manipulation and rounding require specialized knowledge. Code length: Generally appropriate for the algorithm; extensive comments help explain necessary complexity rather than adding needless code. Action granularity: Most statements occupy separate lines, but multiple conditional blocks and closing braces on one line hinder readability. Reading flow: Constants followed by focused helpers provide a natural progression, disrupted by the malformed-looking conditional formatting and the placement of ONE_BITS at the end.

Run 2

Code Structure: Well organized into focused utility methods with named constants, though ONE_BITS is separated from related constants. Nesting: Mostly shallow, but the compressed nested conditional in bigToDouble introduces unnecessary complexity. Clarity of intent: Descriptive method names and detailed comments explain specialized floating-point operations; the negated condition and redundant parentheses obscure a simple range check. Code length: Generally concise for the numerical algorithm, with lengthy but useful rounding explanations. Action granularity: Most lines perform one action, except the nested if statements and braces compressed onto single lines. Reading flow: Methods progress naturally from validation through computation to return values, but inconsistent formatting in bigToDouble disrupts an otherwise readable presentation.

Run 3

Code Structure: Constants and focused utility methods provide logical organization, though ONE_BITS appears after the methods rather than alongside related constants. Nesting: Mostly shallow, but bigToDouble contains an awkward nested conditional with unnecessary negation and parentheses. Clarity of intent: Descriptive names and detailed comments explain the specialized floating-point operations, although bit manipulation requires domain knowledge. Code length: Generally concise; extensive rounding comments are useful rather than redundant. Action granularity: Most statements occupy separate lines, but the compressed nested if and closing braces combine control-flow elements and hinder scanning. Reading flow: Most methods follow a natural sequence, while the malformed-looking conditional layout in bigToDouble interrupts an otherwise consistent presentation.