Modul (%) in python not like in C?

Bryan Olson fakeaddress at nowhere.org
Sat Sep 15 07:56:32 EDT 2007


J. Cliff Dyer wrote:
> Bryan Olson wrote:
>> Scott David Daniels wrote:
>>   
>>> C, which was designed as a "high level assembly language," does not
>>> tightly define the results of / and % for negative numbers.  Instead
>>> it defines the result for positive over positive, and constrains the
>>> result for the others. 
>>>     
>> Not true. Here it is again:
>>
>>      When integers are divided, the result of the / operator is
>>      the algebraic quotient with any fractional part discarded.(87)
>>      If the quotient a/b is representable, the expression
>>      (a/b)*b + a%b shall equal a.
>>      [...]
>>      87) This is often called ‘‘truncation toward zero’’.
>>
>>      [International Standard ISO/IEC 9899:1999, Section 6.5.5
>>      Multiplicative operators, Paragraph 6 and footnote 87]
>>   
> But C was around for a long time before the 1999 standard.  C89,
> commonly called ANSI C, is still very commonly used in compilers, and
> K&R C goes back to 1972.  Is truncation toward 0 the standard for K&R C
> as well? 

Looks like you have a good point there. I do not have a copy of
the C89 standard, but do I have editions of Harbison&Steele that
reflect the 1989 standard, and they confirm your suspicion that
the results of the '/' and '%' operators on integer operants
were not uniquely defined in cases where an operand could be
negative.

Describing the '/' operator:

     For integral operands,, if the mathematical quotient is
     is not an exact integer, then the result will be one of
     the integers closest to the mathematical quotient of the
     operands. Of those two integers, the one closer to 0 must
     be chosen if both operands are positive

Furthermore:

     It is always true that (a/b)*b + a%b is equal to a if b
     is not 0

Quoted from: S. P. Harbison and G. L. Steele. /C: A
Reference Manual, Third Edition/, Prentice Hall, 1991;
Section 7.6.1, page 187.

So Arnau Sanchez and Scott David Daniels were correct with
respect to C89 and older standards, and many implementations
have not yet adopted the 1999 standard that strictly defines
the results of / and %.


-- 
--Bryan



More information about the Python-list mailing list