How this instrument works
Modulo does not ask how many times b divides a — it asks what is left over after removing as many complete copies of b as will fit, and 'as many as will fit' is decided by rounding down, never toward zero. For a positive dividend that distinction never shows itself, because rounding down and rounding toward zero agree completely. The moment a turns negative the two rules split apart, and the remainder that comes out depends entirely on which one the engine follows underneath.
This sheet follows the same convention as Python, Ruby, and most mathematics texts: the remainder always carries the sign of the divisor b, landing somewhere in the half-open interval from 0 up to b. Take a = −7 and b = 3. Removing whole copies of 3 while rounding down means subtracting 3 one more time than intuition suggests — down to −9, not up to −6 — leaving a positive remainder of 2 rather than the −1 a naive 'flip the sign' instinct produces.
When a divides b evenly, the sign question disappears entirely and the remainder collapses to exactly 0, negative dividend or not. The split between conventions has a name in computer science: 'floored' division, which this sheet and Python use, versus 'truncated' division, which C, Java, and JavaScript's percent operator use instead. The identical expression a mod b can legitimately return two different, equally defensible answers depending on which language evaluates it.
- Enter the dividend into the a (may be negative) field — negative, positive, or zero all work.
- Enter the divisor into the b field; it must be a positive number, since b = 0 leaves no remainder to find.
- Read the a mod b field for the remainder — always between 0 and b, whatever sign a carried going in.
- Try a = −7 with b = 3 and confirm the field settles on 2, not −1, the answer a sign-flipping shortcut would suggest.
Worked example — −7 mod 3
Set a to −7 and b to 3, matching a dial with exactly three marked positions, 0, 1, and 2, that wraps around like a rotary combination lock. Rounding a ⁄ b = −2.333… down gives ⌊a ⁄ b⌋ = −3, three whole backward turns rather than two, so the remainder is a − b·⌊a ⁄ b⌋ = −7 − 3×(−3) = −7 + 9 = 2. Seven clicks backward from position 0 lands the dial on position 2, exactly where two full backward laps of the three-position dial would also land.
The tempting shortcut of just negating the positive-number answer is wrong here: 7 mod 3 is 1, so it is easy to guess −7 mod 3 should be −1, but −1 sits outside the required range 0 ≤ result < 3 and is not what this engine, or Python's percent operator, returns. Try a = −10 with b = 5 and the same rule holds even when the division is exact: the dial completes exactly two full backward laps with nothing left over, so the field reads 0, still safely inside 0 ≤ result < 5.
Questions
Why is −7 mod 3 equal to 2 instead of −1?
Because this engine rounds the quotient down, not toward zero, before computing the remainder: ⌊−7 ⁄ 3⌋ = −3, so the remainder works out to −7 − 3×(−3) = 2. The intuitive shortcut of negating 7 mod 3 = 1 to get −1 ignores that the result must satisfy 0 ≤ result < 3, and −1 fails that test while 2 passes it cleanly.
Why does the remainder take the sign of b rather than the sign of a?
It is a convention, not a law of arithmetic. This engine defines a mod b as a − b·⌊a ⁄ b⌋, and because the floor function always rounds toward negative infinity, that formula forces the answer into 0 ≤ result < b whenever b is positive, no matter what sign a started with. Python, Ruby, and most number-theory texts pick this same floored convention.
Does a negative dividend that divides evenly still give a remainder of 0?
Yes. With a = −10 and b = 5, −10 splits into exactly two whole backward groups of 5 with nothing left over, so the field reads 0 rather than any negative value. Zero has no sign to disagree about, which makes it the one case where every rounding convention — floored, truncated, or otherwise — lands on the identical answer.
How is this different from an ordinary positive-number modulo calculator?
An ordinary modulo page with a positive dividend never has to choose between rounding conventions, because rounding down and rounding toward zero agree whenever a and b are both positive. This sheet exists for the case where they disagree: any time a turns negative, the choice of convention changes the answer, and getting that specific choice right is the entire point here.
Which programming languages disagree about negative modulo, and why?
C, Java, and JavaScript's percent operator truncate toward zero, so their version of −7 mod 3 returns −1 — the sign of the dividend. Python, Ruby, and this engine instead floor the quotient first, returning 2 — the sign of the divisor. Neither convention is a bug; they answer the floor-versus-truncate question differently, so code moving between languages needs to know which rule it is inheriting.
Can the divisor b itself be negative on this sheet?
No — the b field enforces a minimum just above zero, so only positive divisors are accepted here. A negative divisor is mathematically definable under the same floored rule, but it flips which end of the interval the remainder gets pinned to, and every check this sheet verifies itself against uses a positive b.