Sample

int-03d0d548cb92-I05

Rewrite eligible decimal integer literals in hexadecimal notation

Matched original source

Lines119

Scores

MethodScoreScale
Posnett00–1; higher is more readable
Scalabrino0.7810–1; higher is more readable
Dorn0.3350–1; higher is more readable
Mi0.6070–1; higher is more readable
LLOC41Logical lines; fewer is more readable
DeepSeek V4 Pro16.330–20; mean of three runs
GPT-6.1 Sol170–20; mean of three runs
BTTF0.4350–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 = 0x34; static final int EXPONENT_BIAS = 0x3ff; /** The implicit 1 bit that is omitted in significands of normal doubles. */ static final long IMPLICIT_BIT = SIGNIFICAND_MASK + 0x1; 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 - 0x1) ? bits << 0x1 : 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() - 0x1; // exponent == floor(log2(abs(x))) if (exponent < Long.SIZE - 0x1) { 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 - 0x1; long twiceSignifFloor = absX.shiftRight(shift).longValue(); long signifFloor = twiceSignifFloor >> 0x1; 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 & 0x1) != 0x0 && ((signifFloor & 0x1) != 0x0 || absX.getLowestSetBit() < shift); long signifRounded = increment ? signifFloor + 0x1 : 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.3614.465−119.277
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.13−7.695

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

Score0.781

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.85+1.251
Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right.105.075+0.891
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.105.975−0.823
Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *.0.058+0.382

Intercept 0.07 + feature contributions = -0.687 (log-odds).
Score = sigmoid(-0.687) = 0.335.

Score0.607
Score41
Run 1

The code is highly readable numeric utility code. Structure is logical: constants, simple getters, normalization, conversion, and a helper. Nesting is minimal—only a two-level conditional in bigToDouble. Intent is clear from meaningful names and comments, especially around tricky bit manipulation and rounding logic. Length is appropriate; verbose comments are justified for non-obvious algorithms. Action granularity is mostly one action per line, though some dense bitwise expressions occur in the conversion method. Reading flow is natural, with constants grouped by purpose and methods progressing from simple to complex. Minor deductions: use of hex literals like 0x1/0x0 slightly reduces readability compared to plain 1/0, and a few long bit-shift lines could be broken down, but overall this is exemplary low-level numerical code.

Run 2

The code is generally well-structured and readable, with a clear organization into constants, helper methods, and a primary conversion method. It uses static imports effectively. The main readability strengths are good naming, logical grouping, and explanatory comments for complex bit manipulation. However, it loses points due to moderately dense bitwise logic in `bigToDouble`, which requires careful study, and some nested conditional logic. The use of hex constants like `0x1` and `0x3ff` instead of clearer decimal or named equivalents slightly reduces clarity. Action granularity is mostly one action per line, and reading flow is natural for the most part, though the long comments break up the flow in the central method.

Run 3

The code is well-structured and readable for a low-level utility class. It uses constants with clear names, keeps methods small and cohesive, and minimizes deep nesting. Each method has a single clear purpose, and complex logic is broken into readable steps with inline comments explaining non-obvious bit manipulation. Some areas, such as the bigToDouble method, could be clearer due to magic numbers and dense bitwise operations, but overall action granularity and reading flow are good. The use of comments and descriptive variable names improves clarity of intent. Minor deductions for the heavy use of bit-level code and magic numbers in places.

Run 1

Code Structure: Well-organized utility class with focused methods and named constants; ONE_BITS would fit more naturally alongside the other constants. Nesting: Very shallow, with simple conditionals and early returns. Clarity of intent: Descriptive names and detailed comments explain the floating-point representation and rounding algorithm, although abbreviated significand variables, hexadecimal small integers, and dense bitwise expressions require careful reading. Code length: Generally concise; the longer bigToDouble method is justified by its specialized algorithm and explanatory comments. Action granularity: Statements mostly perform one action per line, with intermediate variables separating computation stages; the rounding predicate combines several conditions densely. Reading flow: Methods proceed naturally from validation and extraction to computation and return, while comments guide the complex conversion logic. Minor formatting issues and a misleading 'not a normal value' validation message slightly reduce readability.

Run 2

Code Structure: Cohesive utility class with focused methods and named bit-mask constants; ONE_BITS would fit more naturally alongside other constants. Nesting: Minimal nesting and early returns keep control flow straightforward. Clarity of intent: Descriptive method names and detailed comments explain complex floating-point operations, although abbreviated variables, hexadecimal small integers, and dense rounding expressions increase cognitive load. Code length: Appropriately concise for specialized numerical logic; longer comments mostly provide valuable context. Action granularity: Statements generally perform one action each, with intermediate variables separating calculation stages; the increment expression combines several conditions. Reading flow: Consistent formatting and sequential computation make methods easy to follow, but tightly packed imports and occasional misleading terminology, such as the finite-value check's 'not a normal value' message, slightly reduce readability.

Run 3

Code Structure: Well-organized utility class with named constants and focused methods; ONE_BITS would fit more naturally alongside the other constants. Nesting: Very shallow, with early returns keeping the conversion algorithm mostly linear. Clarity of intent: Descriptive method names and detailed comments explain specialized floating-point operations, though hexadecimal small integers, abbreviated variables, and a dense rounding condition increase cognitive effort. Code length: Mostly concise; the longer bigToDouble method is justified by its algorithm and explanatory comments. Action granularity: Statements generally perform one action per line, with intermediate variables making transformations traceable. Reading flow: Consistent formatting and sequential computation support natural reading, although understanding bit manipulation requires domain knowledge and occasional rereading.