<p>The <code>%</code> operator in most programming language provide a remainder from integer division. When both operands are positive all works as expected. But when the number is negative there is a difference between Euclidean modulo and remainder.</p>
<p>The Euclidean division modulo will always be positive if the divisor is positive. In this case <code>a % b</code> will have the range <code>[0, b)</code> provided <code>b</code> is positive. This is where <code>&amp; (powerof2 - 1)</code> is equivalent to <code>% powerof2</code>. <code>(-1) &amp; 15</code> is <code>15</code>, and assuming Euclidean division, <code>(-1) % 16</code> is also <code>15</code>.</p>
<p>This is not the case for non-Euclidean remainder, where <code>a % b</code> would have the range <code>[-b, b)</code>. This would result in negative numbers, causing problems for operations such as normalizing angles between 0 and 360 degrees etc. <code>(-1) % 16</code> in this case would be <code>-1</code>.</p>
<p>Given that there is only one <code>%</code> operator, how could a programming language allow a programmer to differentiate between these distinct ways to handle negatives in modulo/remainder operations?</p>

<syntax><operators><math><division><modulo>
Distinguishing modulo (Euclidean division) from remainder
CC BY-SA 4.0
2023-05-19T14:40:42.127Z
@justANewbie The latter
CPlus
CC BY-SA 4.0
2023-06-30T11:47:47.980Z
Please note that there exist languages which have both a `mod` and a `rem` operator, or both a `modulo` and a `remainder` operator, and if you take two languages that do, you'll probably find that the two languages ***do not agree*** about which name corresponds to which convention. For instance, it would make sense to name "mod" the operator that follows the same convention as C language's `%`, and to name "rem" the operator that corresponds to the remainder in the Euclidean division; and that is the exact opposite of the definitions in your question.
Stef
CC BY-SA 4.0
2023-06-30T12:03:41.910Z
Also, your question makes the assumption that there are only two possible conventions, but in the expression `a % b` there are four possible combinations of the signs of a and b, and there is a non-obvious choice to make for at least three of these combinations (only a negative, only b negative, both negative); so in theory there could be up to 8 different conventions; and [Wikipedia lists 5 of these conventions](https://en.wikipedia.org/wiki/Modulo#Variants_of_the_definition) as actually in use, which they refer to as "truncated, rounded, floored, ceiled, Euclidean".
Stef
CC BY-SA 4.0
2023-07-21T13:32:26.190Z
A similar problem is present in the rounding of integer division with negatives. And both issues are probably related. E.g. x86 `div`/`idiv` compute both quotient and reminder.
Pablo H
CC BY-SA 4.0
2023-05-17T02:32:38.657Z
"differentiate" as in letting the programmer easily know the difference, or provide options for a programmer?
justANewbie
<p>One solution I thought of that would remove the ambiguity problems with <code>%</code> and <code>%%</code> would be to use <code>&amp;%</code> for proper modulo and <code>%</code> for remainder. Since <code>&amp;</code> with a one less than power of 2 is reminiscent of proper modulo by power of 2, combining <code>&amp;</code> with <code>%</code> to result in a proper Euclidean modulo operation would be consistent.</p>

CC BY-SA 4.0
2023-05-18T04:46:13.633Z
2023-05-18T04:46:13.633Z
CPlus
<p>I support Bbrk24's answer, but to add on; whether you use <code>%</code> or <code>%%</code> for Euclidean modulo, you should consider what the target programmers will be more inclined to use. If you predict your language is for JavaScript V8 users, use <code>%</code> for the remainder and <code>%%</code> for Euclidean modulo. If it is for Python, set it the other way around.</p>
<p>This all depends on who you think is going to use your language. Else you'll have disgruntled programmers complaining about having to put weird symbols just to get the intended result when modulo-ing.</p>

CC BY-SA 4.0
2023-05-17T04:48:55.733Z
2023-05-17T04:48:55.733Z
SectorCorruptor
CC BY-SA 4.0
2023-06-30T12:10:38.530Z
If it's python you could have a `with floored_division:` or `with truncated_division:` environment to modify the behaviour of `//` and `%` ;-p
Stef
<p>Given the usefulness of a proper modulo operator to wrap an integer into a range <code>[0, n)</code> e.g. for an array index or generating a random integer in this range, I find this far more useful than the remainder operator.</p>
<p>Personally if I were to implement both in a language, I would make <code>%</code> the modulo operator and relegate remainders to a function in the standard library, perhaps <code>rem(a, b)</code> for just the remainder and <code>divrem(a, b)</code> for computing both a truncated division and remainder. I just don't see any use for the remainder operator so I don't see any value in having a specific syntax for it.</p>
<p>If you do want both to be operators, another option is to use keywords instead of punctuation, so e.g. <code>a mod b</code> and <code>a rem b</code> to distinguish between them. (This goes better if other operators in your language, like <code>and</code>, <code>or</code> and <code>not</code>, are also keywords.) An upside is that words are much easier to search for online compared to punctuation, for users who don't know the meaning of these operators or the difference between them.</p>

CC BY-SA 4.0
2023-05-17T05:05:42.767Z
2023-05-17T05:05:42.767Z
kaya3
CC BY-SA 4.0
2023-05-27T04:09:38.750Z
Why requiring keywords for operators when identifiers do the job? Scala's `x mod y` is the same as `x.mod(y)`, Haskell's ``x `mod` y`` and Ante's `x .mod y` are the same as `mod x y`.
Longinus
CC BY-SA 4.0
2023-05-27T09:46:12.347Z
@Longinus I think that's a separate question.
kaya3
<p>There are two great articles investigating this question:</p>
<ol>
<li><a href="https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/divmodnote-letter.pdf" rel="noreferrer">Division and Modulus for Computer Scientists</a> by Daan Leijen</li>
<li><a href="https://dl.acm.org/doi/pdf/10.1145/128861.128862" rel="noreferrer">The Euclidean Definition of the Functions div and mod</a> by Raymond Boute</li>
</ol>
<p>In short, div-mod operations come in pairs satisfying the equation</p>
<pre><code>x = (x/n)*n + (x%n)
</code></pre>
<p>This means that if we define one of the two operations, then we have no choice for the other operation because it is already determined by that equation.</p>
<p>We can define division in these ways:</p>
<ol>
<li>Round up (ceil)</li>
<li>Round down (floor)</li>
<li>Round nearest (round)</li>
<li>Round toward zero (truncate)</li>
</ol>
<p>It turns out that round down has the most useful corresponding modulo operation, because the modulo operation associated with round down always produces a number x%n in [0,n) whenever n is positive, even if x is negative.</p>
<p>There is a fifth option, called Euclidean div-mod, which postulates that x%n should always be in the range [0,abs(n)) <em>even if n is negative</em>. This then has an associated div operation that is different from any of the four listed above.</p>
<p>The articles conclude that these are the only two sensible options for a div-mod pair:</p>
<ol>
<li>Floor: mod gives a number in the range [0,n), div is floored division</li>
<li>Euclidean: mod gives a number in the range [0,abs(n)), then define div in terms of the equation above</li>
</ol>
<p>These two choices only differ when the divisor n is negative. They agree when n is positive, even when x is negative.
Furthermore, it is easy to define option 1 in terms of option 2 and vice versa. The floor div-mod just gives a number in the range [0,n) always, even if n is negative. That is, if n=-10, then the floor mod operation gives a number in the range (-10,0]. In other words, the sign of x%n is the same as the sign of n for the floor option, whereas the sign of x%n is always positive for the Euclidean option.</p>
<p>The articles argue that Euclidean is better because it results in a slightly better mod operation. However, the floor option has the following advantages:</p>
<ol>
<li>The floored div operation is easy to understand: div(x,n) = floor(x/n). It's a bit less clear what the Euclidean div means for negative n.</li>
<li>These two options only differ for negative divisors, and mod with a negative divisor is almost never useful, but div with a negative divisor is occasionally useful.</li>
<li>It is easy to get the Euclidean mod using the floored mod: <code>mod_euclid(x,n) = x % abs(n)</code>. I would argue that if your code is doing mod with negative divisors, then it is in fact clearer to have that explicit <code>abs</code> in your code as a signifier that something is going on.</li>
</ol>
<p>On the other hand, it is true that Euclidean div-mod makes it more natural to convert numbers to negative base with positive digits.</p>
<p>In my opinion, either of these two options is fine.</p>

CC BY-SA 4.0
2023-05-18T08:59:37.267Z
2023-05-18T10:05:42.920Z
2023-05-18T10:05:42.920Z
Jules
<p>One could always take the route of C's pairs of &quot;and&quot; and &quot;or&quot; operators -- call one <code>%</code> and the other <code>%%</code>.</p>

CC BY-SA 4.0
2023-05-17T02:32:06.987Z
2023-05-17T02:32:06.987Z
Bbrk24
# Distinguishing modulo (Euclidean division) from remainder
Posted by: username_0 on 2023-05-17
The `%` operator in most programming language provide a remainder from integer division. When both operands are positive all works as expected. But when the number is negative there is a difference between Euclidean modulo and remainder.

The Euclidean division modulo will always be positive if the divisor is positive. In this case `a % b` will have the range `[0, b)` provided `b` is positive. This is where `& (powerof2 - 1)` is equivalent to `% powerof2`. `(-1) & 15` is `15`, and assuming Euclidean division, `(-1) % 16` is also `15`.

This is not the case for non-Euclidean remainder, where `a % b` would have the range `[-b, b)`. This would result in negative numbers, causing problems for operations such as normalizing angles between 0 and 360 degrees etc. `(-1) % 16` in this case would be `-1`.

Given that there is only one `%` operator, how could a programming language allow a programmer to differentiate between these distinct ways to handle negatives in modulo/remainder operations?
**Tags:** syntax operators math division modulo
> **Comments:**
> **username_3**: "differentiate" as in letting the programmer easily know the difference, or provide options for a programmer?  
> **username_0**: @justANewbie The latter  
> **username_1**: Please note that there exist languages which have both a `mod` and a `rem` operator, or both a `modulo` and a `remainder` operator, and if you take two languages that do, you'll probably find that the two languages ***do not agree*** about which name corresponds to which convention. For instance, it would make sense to name "mod" the operator that follows the same convention as C language's `%`, and to name "rem" the operator that corresponds to the remainder in the Euclidean division; and that is the exact opposite of the definitions in your question.  
> **username_1**: Also, your question makes the assumption that there are only two possible conventions, but in the expression `a % b` there are four possible combinations of the signs of a and b, and there is a non-obvious choice to make for at least three of these combinations (only a negative, only b negative, both negative); so in theory there could be up to 8 different conventions; and [Wikipedia lists 5 of these conventions](https://en.wikipedia.org/wiki/Modulo#Variants_of_the_definition) as actually in use, which they refer to as "truncated, rounded, floored, ceiled, Euclidean".  
> **username_2**: A similar problem is present in the rounding of integer division with negatives. And both issues are probably related. E.g. x86 `div`/`idiv` compute both quotient and reminder.  
---
## 5 answers
### Answer by username_5 on 2023-05-17. Score: 12 | Accepted answer
Given the usefulness of a proper modulo operator to wrap an integer into a range `[0, n)` e.g. for an array index or generating a random integer in this range, I find this far more useful than the remainder operator.

Personally if I were to implement both in a language, I would make `%` the modulo operator and relegate remainders to a function in the standard library, perhaps `rem(a, b)` for just the remainder and `divrem(a, b)` for computing both a truncated division and remainder. I just don't see any use for the remainder operator so I don't see any value in having a specific syntax for it.

If you do want both to be operators, another option is to use keywords instead of punctuation, so e.g. `a mod b` and `a rem b` to distinguish between them. (This goes better if other operators in your language, like `and`, `or` and `not`, are also keywords.) An upside is that words are much easier to search for online compared to punctuation, for users who don't know the meaning of these operators or the difference between them.
> **Comments:**
> **username_6** (2023-05-27): Why requiring keywords for operators when identifiers do the job? Scala's `x mod y` is the same as `x.mod(y)`, Haskell's ``x `mod` y`` and Ante's `x .mod y` are the same as `mod x y`.  
> **username_5** (2023-05-27): @Longinus I think that's a separate question.  
---
### Answer by username_7 on 2023-05-18. Score: 11
There are two great articles investigating this question:

Division and Modulus for Computer Scientists by Daan Leijen
The Euclidean Definition of the Functions div and mod by Raymond Boute

In short, div-mod operations come in pairs satisfying the equation
x = (x/n)*n + (x%n)

This means that if we define one of the two operations, then we have no choice for the other operation because it is already determined by that equation.
We can define division in these ways:

Round up (ceil)
Round down (floor)
Round nearest (round)
Round toward zero (truncate)

It turns out that round down has the most useful corresponding modulo operation, because the modulo operation associated with round down always produces a number x%n in [0,n) whenever n is positive, even if x is negative.
There is a fifth option, called Euclidean div-mod, which postulates that x%n should always be in the range [0,abs(n)) even if n is negative. This then has an associated div operation that is different from any of the four listed above.
The articles conclude that these are the only two sensible options for a div-mod pair:

Floor: mod gives a number in the range [0,n), div is floored division
Euclidean: mod gives a number in the range [0,abs(n)), then define div in terms of the equation above

These two choices only differ when the divisor n is negative. They agree when n is positive, even when x is negative.
Furthermore, it is easy to define option 1 in terms of option 2 and vice versa. The floor div-mod just gives a number in the range [0,n) always, even if n is negative. That is, if n=-10, then the floor mod operation gives a number in the range (-10,0]. In other words, the sign of x%n is the same as the sign of n for the floor option, whereas the sign of x%n is always positive for the Euclidean option.
The articles argue that Euclidean is better because it results in a slightly better mod operation. However, the floor option has the following advantages:

The floored div operation is easy to understand: div(x,n) = floor(x/n). It's a bit less clear what the Euclidean div means for negative n.
These two options only differ for negative divisors, and mod with a negative divisor is almost never useful, but div with a negative divisor is occasionally useful.
It is easy to get the Euclidean mod using the floored mod: mod_euclid(x,n) = x % abs(n). I would argue that if your code is doing mod with negative divisors, then it is in fact clearer to have that explicit abs in your code as a signifier that something is going on.

On the other hand, it is true that Euclidean div-mod makes it more natural to convert numbers to negative base with positive digits.
In my opinion, either of these two options is fine.
---
### Answer by username_8 on 2023-05-17. Score: 5
One could always take the route of C's pairs of "and" and "or" operators -- call one `%` and the other `%%`.
---
### Answer by username_4 on 2023-05-17. Score: 3
I support Bbrk24's answer, but to add on; whether you use `%` or `%%` for Euclidean modulo, you should consider what the target programmers will be more inclined to use. If you predict your language is for JavaScript V8 users, use `%` for the remainder and `%%` for Euclidean modulo. If it is for Python, set it the other way around.

This all depends on who you think is going to use your language. Else you'll have disgruntled programmers complaining about having to put weird symbols just to get the intended result when modulo-ing.
> **Comments:**
> **username_1** (2023-06-30): If it's python you could have a `with floored_division:` or `with truncated_division:` environment to modify the behaviour of `//` and `%` ;-p  
---
### Answer by username_0 on 2023-05-18. Score: 0
One solution I thought of that would remove the ambiguity problems with `%` and `%%` would be to use `&%` for proper modulo and `%` for remainder. Since `&` with a one less than power of 2 is reminiscent of proper modulo by power of 2, combining `&` with `%` to result in a proper Euclidean modulo operation would be consistent.
---
