Numbers & Arithmetic — When the Type Decides the Answer

Java's arithmetic looks like the maths you already know — +, -, *, / — but it obeys one rule the maths classroom never mentioned: the result is shaped by the operands' types, not by the answer you have in mind. Divide two integers and the fraction vanishes; push an int past its range and it wraps silently to a negative number; mix an int with a double and the whole expression becomes a double. The same / means different things depending on what sits to its left and right. This chapter is about reading those types so the numbers come out right.

This builds directly on the primitive types — the sizes and ranges from that chapter are exactly what decides each result here. Every output below was produced by compiling and running the code.

Table of contents

1. The arithmetic operators
2. Integer division truncates
3. Mixing numeric types, and casting
4. Silent integer overflow
5. Precedence and the Math class
6. Mental-model summary
7. Gotcha checklist

1. The arithmetic operators

Five operators do the everyday arithmetic: + add, - subtract, * multiply, / divide (its own section, next), and % remainder — what is left over after a division.

Output:

9
5
14
1

Analysis. 7 + 2 = 9, 7 - 2 = 5, 7 * 2 = 14, and 7 % 2 = 1 because 7 is 3 * 2 + 1 — the remainder is 1. % is how you test divisibility (n % 2 == 0 means "even") and how you fold a value into a range.

Intuition. Mechanism. % returns the remainder, and in Java its sign follows the left operand (the dividend), not the right.

Concrete bite. So it is not quite the mathematical "modulo," which is always non-negative:

Output:

-1
1

-7 % 2 is -1, not 1 — the result took the sign of -7. 7 % -2 is 1, taking the sign of 7. The magnitude is the remainder; the sign comes from the dividend.

2. Integer division truncates

/ between two integers is integer division: it gives the whole-number quotient and discards the remainder.

Output:

3
0
0

Analysis. 7 / 2 is 3 (not 3.5), 1 / 2 is 0, and 9 / 10 is 0. The fraction is not rounded — it is truncated, dropped toward zero. Both operands are int, so the result is an int, and an int has nowhere to keep a fractional part.

Intuition. Mechanism. When both operands are integer types, / computes the integer quotient; the result type is that integer type, so a fractional part simply cannot exist.

Concrete bite. The average bug — a double result produced one step too late:

Output:

3.0

Even though average is a double, the right-hand side total / count is int / int, evaluated first — as 3 — and only then widened to 3.0. The division already happened in integer-land; widening the answer afterward cannot recover the lost .5. So the "average" of 7 and 2 prints 3.0.

3. Mixing numeric types, and casting

When operands have different numeric types, Java promotes the narrower to the wider before computing: int / double becomes double / double. To force a type yourself, cast with (type) written in front of a value.

Output:

3.5
3.5
3

Analysis. 7 / 2.0: the 2.0 is a double, so 7 is promoted to 7.0 and the division is 7.0 / 2.0 = 3.5. (double) total / count: the cast turns total into 7.0 first — and (double) binds to just total — so it is 7.0 / 2 = 3.5. And (int) 3.9 is a narrowing cast: it chops the fraction, giving 3 (toward zero — (int) 3.9 is 3, not 4).

Intuition. Mechanism. A cast (double) x produces a value of the target type for that one spot; automatic promotion does the same when types mix. Precedence matters: a cast binds tightly, to the operand immediately after it — (double) total / count casts total, then divides.

Concrete bite. Cast the result instead of an operand and the bug survives:

Output:

3.0

The parentheses force 7 / 2 first (integer division → 3), and only then cast 3 to 3.0. You converted the answer after the fraction was already gone. Contrast (double) 7 / 2, which casts 7 first and gives 3.5.

4. Silent integer overflow

An int is 32 bits, with a range of about −2.1 billion to +2.1 billion. When arithmetic produces a result outside that range, Java does not grow the type to fit — it wraps around, silently, to the opposite end. There is no error at all.

Output:

2147483647
-2147483648

Analysis. Integer.MAX_VALUE is the largest int, 2147483647. Add 1 and, instead of 2147483648, you get -2147483648 — the smallest int. The value rolled over the top of the range straight to the bottom, like a car odometer passing its maximum. No exception, no warning; just a negative number where a larger positive was expected.

Intuition. Mechanism. int + int is always an int. The result keeps only the low 32 bits; when the true answer would need a 33rd bit, that bit is discarded, and because of how signed integers are encoded, discarding it flips the sign. The type never widens itself to fit.

Concrete bite. It hides in ordinary code — a product of two modest numbers:

Output:

1410065408

100000 * 100000 is ten billion, far beyond an int, so it wraps to a meaningless 1410065408. Nothing looked dangerous; the type quietly betrayed the arithmetic.

Output (a thrown exception; the full stack trace follows the first line, pointing at the multiplyExact call):

Exception in thread "main" java.lang.ArithmeticException: integer overflow

Swapping a silent wrong answer for a loud ArithmeticException is usually the trade you want. (Exceptions get their full treatment in Tutorial 24, in Tier 4.)

5. Precedence and the Math class

When several operators meet in one expression, Java follows precedence: *, /, and % bind tighter than + and -, and parentheses override the order. For arithmetic beyond the basic operators, the Math class supplies sqrt, pow, abs, max, min, and more.

Output:

14
20
10
12.0
1024.0

Analysis. 2 + 3 * 4 is 2 + 12 = 14, because * binds tighter than +; parentheses force 5 * 4 = 20. Math.max returns the larger value; Math.sqrt(144.0) is 12.0; and Math.pow(2, 10) is 1024.0 — note the .0: Math.pow always returns a double, so even a whole-number power comes back as a decimal.

Intuition. Mechanism. Precedence is fixed grammar the compiler applies before anything runs; Math.pow and Math.sqrt are library methods that take and return double.

Concrete bite. Assuming Math.pow yields an integer bites the moment you try to store its result in an int:

Compiler error:

Main.java:3: error: incompatible types: possible lossy conversion from double to int
        int kib = Math.pow(2, 10);
                          ^
1 error

Math.pow returns 1024.0, a double, and a double will not fit into an int without losing its fractional part — so the compiler refuses. The fix is a deliberate cast, int kib = (int) Math.pow(2, 10);, which gives 1024.

6. Mental-model summary

7. Gotcha checklist

Your Turn

Before you move on, check your understanding with the coach — explain the idea, apply it, weigh the trade-offs, then defend your reasoning.