Source code
public class LeylandNumbers {
public static void main(String[] args) {
long max = 100000000000L;
for (long x = 2; x * x < max; x++) {
for (long y = 2; y <= Math.pow(max, 1.0 / (x - 1)); y++) {
long n = (long) (Math.pow(x, y) + Math.pow(y, x));
if (n >= max) {
break;
}
System.out.println(n);
}
}
}
}
Run 1
The code is short and readable at a glance, but it lacks structure and clarity. Variables 'x' and 'y' are generic, the condition in the outer loop (x * x < max) is not self-explanatory, and the inner loop bound using Math.pow is unclear and potentially lossy. The action granularity is acceptable, and nesting depth is minimal, but the algorithm's intent is obscured. There is no handling of duplicates — Leyland numbers may repeat — and the use of floating-point operations for integer calculation introduces precision issues. The code compiles and is concise, but not robust or self-documenting.
Run 2
The code is short and logically structured, but its intent is ambiguous due to poor naming and unclear boundary logic. The nesting is acceptable, with two loops and one conditional. However, the variable names (max, x, y, n) do not convey meaning, and the use of Math.pow for integer arithmetic is misleading and inefficient. The loop condition y <= Math.pow(max, 1.0 / (x - 1)) is non-obvious and hard to understand without domain knowledge. Action granularity is reasonable, with one main operation per line. Reading flow is disrupted by the unclear stopping condition and lack of comments or explanation. Overall, the code is concise but sacrifices clarity.
Run 3
The code is short and reasonably structured, with two clear loops and a simple output. However, readability suffers due to unclear intent: the class name and variable names (x, y, max, n) are generic and do not explain that Leyland numbers are being generated. The loop conditions and the Math.pow bound calculation are nontrivial and require domain knowledge to understand; there is no comment explaining the mathematical logic. Nesting is shallow, and action granularity is mostly one action per line. Reading flow is moderate, as the outer loop condition (x * x < max) is a rough heuristic, while the inner loop bound based on Math.pow is hard to parse. Overall, the code is concise but not self-explanatory, making it moderately difficult to read without prior context.
Run 1
Code Structure: The class and main method organize the calculation logically, though a separate generation method could improve separation of concerns. Nesting: Two loops and one conditional create moderate, manageable nesting. Clarity of intent: The class name identifies the purpose, but the mathematical loop bounds and exponent calculation lack explanation; max and n could have more descriptive names. Code length: Compact without unnecessary statements. Action granularity: Each statement performs a distinct action, with conventional loop controls. Reading flow: Initialization, iteration, calculation, limit checking, and output follow a natural sequence, although understanding the bounds requires mathematical inference.
Run 2
Code Structure: A single, logically organized method computes and prints Leyland numbers. Nesting: Two nested loops and an if statement create moderate nesting, but the short body remains easy to follow. Clarity of intent: The class name and formula communicate the purpose, though the unexplained loop bounds and abbreviated variables require mathematical interpretation. Code length: Compact without unnecessary statements. Action granularity: Each statement performs a distinct action, with calculation, limit checking, and output separated. Reading flow: Consistent indentation and a natural compute-check-print sequence support readability. Named constants and brief explanations of the bounds would improve clarity.
Run 3
Code Structure: A single main method logically groups initialization, iteration, calculation, filtering, and output. Nesting: Two loops and an if statement create moderate, manageable nesting. Clarity of intent: The class name and formula suggest Leyland number generation, but terse variable names, an unexplained maximum, and especially the mathematical inner-loop bound require interpretation. Code length: Compact without obvious redundancy or unnecessary boilerplate. Action granularity: Statements generally perform one action per line, although the calculation combines exponentiation, addition, and casting. Reading flow: Consistent indentation and a straightforward calculate-check-print sequence make execution easy to follow; named constants or a brief explanation of the bounds would improve readability.