Why do such operations:
std::cout << (-7 % 3) << std::endl; std::cout << (7 % -3) << std::endl; give different results?
-1 1 
Add a comment |
3 Answers
From ISO14882:2011(e) 5.6-4:
The binary / operator yields the quotient, and the binary % operator yields the remainder from the division of the first expression by the second. If the second operand of / or % is zero the behavior is undefined. For integral operands the / operator yields the algebraic quotient with any fractional part discarded; if the quotient a/b is representable in the type of the result, (a/b)*b + a%b is equal to a.
The rest is basic math:
(-7 / 3) => -2 -2 * 3 => -6 so a % b => -1 (7 / -3) => -2 -2 * -3 => 6 so a % b => 1 Note that
If both operands are nonnegative then the remainder is nonnegative; if not, the sign of the remainder is implementation-defined.
from ISO14882:2003(e) is no longer present in ISO14882:2011(e)
8 Comments
James Kanze
The expression "algebraic quotient" isn't present in ISO 14882:2003; the expression there is just "quotient" (and what is implementation defined is whether
-7/3 results in -2 or -3).
Kerrek SB
I think no matter which way and how many times you skin that cat, the fundamental fact is that divide and modulo with signed operands is implementation defined. There's always a "which way" choice in some guise or another. The guaranteed identity at the end of that quote is what's important. (Though I think C99 may actually fix that choice.)
PlasmaHH
@JamesKanze: C++03 still contains the implementation definedness, it is C++11 which removes it. (and requires divisions to follow fortran, basically)
Buge
@KerrekSB It is defined now in C++11.
Kerrek SB
@Buge: C++11 is based on C99, so that makes sense.
|
a % b in c++ default:
(-7 / 3) => -2 -2 * 3 => -6 so a % b => -1 (7 / -3) => -2 -2 * -3 => 6 so a % b => 1 in python:
-7 % 3 => 2 7 % -3 => -2 in c++ to python:
(b + (a % b)) % b 1 Comment
Sebastian Mach
There is no "C++ default" regarding the resulting sign in case of negative numbers.
The sign in such cases (i.e when one or both operands are negative) is implementation-defined. The spec says in §5.6/4 (C++03),
The binary / operator yields the quotient, and the binary % operator yields the remainder from the division of the first expression by the second. If the second operand of / or % is zero the behavior is undefined; otherwise (a/b)*b + a%b is equal to a. If both operands are nonnegative then the remainder is nonnegative; if not, the sign of the remainder is implementation-defined.
That is all the language has to say, as far as C++03 is concerned.
14 Comments
James Kanze
That's all the language had to say. C++11 (like C99) adopts the Fortran rules of rounding to zero (i.e. dropping the fractional part). In practice, all hardware had adopted the Fortran rules long ago, so all all implementations already did it this way anyway. (The purpose of the "implementation-defined" is to allow C/C++ to do whatever the hardware does. I think some very old hardware did always round down, so that
-7/3 would result in -3, but that would be in a very distant past.)
supercat
@JamesKanze: If
b is a power of 2, it used to be possible to compute n % b as n & (b-1). The new standard requires that it be computed as n < 0 ? n | -b : n & (b-1). Likewise, n / b cannot be written as a simple shift, even on hardware that supports arithmetic shifts; instead, on such systems, an expression like n/16 (if n is an int32) must be written as n < 0 ? (n+15) >> 4 : n >> 4. Horrible standard, IMHO. Note that since non-power-of-two division is inherently slow anyway, mandating Euclidian behavior wouldn't have slowed it down much.supercat
@JamesKanze: It is NOT the behavior of existing hardware in the case of optimizing divide-by-power-of-two operations as shifts. Under the old rules,
foo /= 16 could be written as asr [dword foo],4. Under the new rules, the optimal representation requires many more instructions [perhaps mov eax,[foo] / mov ebx,eax, asr eax,31 / lsr eax,28 / add eax,ebx / asr eax,4 / mov [foo],eax] Not as slow as a divide instruction, but a lot more work than a simple shift.
CptRobby
@supercat Complaining about the way that an arithmetic function in a human readable language works because of how many instructions have to be done in machine code to keep it consistent instead of using a hacky shortcut that only simplifies operations with a tiny subset of all possible values? Wow. Just wow. slow clap
Martin
@CptRobby You seem to forget that the entire design philosophy of C revolves around hacky shortcuts to produce faster assembly code.
|