-1 % 16 = -1

Shouldn't that be 15? It seems like the sign is ignored for the modulo.

Is this a bug or intended behaviour? The Python implementation returns here, as expected, 15.

On Saturday, 11 August 2012 at 13:48:16 UTC, David wrote:
> -1 % 16 = -1
>
> Shouldn't that be 15? It seems like the sign is ignored for the modulo.
>
> Is this a bug or intended behaviour? The Python implementation returns here, as expected, 15.

From the language spec:

"For integral operands of the / and % operators, the quotient rounds towards zero and the remainder has the same sign as the dividend."

http://dlang.org/expression.html

In your case, the dividend is -1, so the remainder has the same sign (-ve). The quotient rounds towards zero, so in this case the quotient is zero, so the remainder must be -1.

Different programming languages handle it differently. In C and C++ it is implementation defined! (C++11 makes it the same as in D)

See: http://en.wikipedia.org/wiki/Modulo_operation

On Saturday, 11 August 2012 at 13:48:16 UTC, David wrote:
> -1 % 16 = -1
>
> Shouldn't that be 15? It seems like the sign is ignored for the modulo.
>
> Is this a bug or intended behaviour? The Python implementation returns here, as expected, 15.

http://en.wikipedia.org/wiki/Modulo_operation

David

Am 11.08.2012 16:00, schrieb Peter Alexander:
> On Saturday, 11 August 2012 at 13:48:16 UTC, David wrote:
>> -1 % 16 = -1
>>
>> Shouldn't that be 15? It seems like the sign is ignored for the modulo.
>>
>> Is this a bug or intended behaviour? The Python implementation returns
>> here, as expected, 15.
>
>  From the language spec:
>
> "For integral operands of the / and % operators, the quotient rounds
> towards zero and the remainder has the same sign as the dividend."
>
> http://dlang.org/expression.html
>
> In your case, the dividend is -1, so the remainder has the same sign
> (-ve). The quotient rounds towards zero, so in this case the quotient is
> zero, so the remainder must be -1.
>
> Different programming languages handle it differently. In C and C++ it
> is implementation defined! (C++11 makes it the same as in D)
>
> See: http://en.wikipedia.org/wiki/Modulo_operation


Thanks! I thought modulo should alawys yield the same ... seems like I was wrong ;)

David:

> -1 % 16 = -1
>
> Shouldn't that be 15? It seems like the sign is ignored for the modulo.
>
> Is this a bug or intended behaviour? The Python implementation returns here, as expected, 15.

It's a localized but important design bug of languages like C that D has carried over for backward compatibility reasons. D % has caused bugs in my code. I suggest to not use the built-in % on numbers that can be negative, unless you really know what you are doing.

Bye,
bearophile

David:

> Thanks! I thought modulo should alawys yield the same ... seems like I was wrong ;)

It's C design that's wrong.

Bye,
bearophile

On 11.08.2012 18:13, bearophile wrote:
> David:
>
>> Thanks! I thought modulo should alawys yield the same ... seems like I
>> was wrong ;)
>
> It's C design that's wrong.

And it's the processor design that makes it inefficient to correct it nowadays.

Python's definition of modulo is far more useful than C's. Implemented in machine code, however, it takes several additional commands because the integer division is hardwired to the C definition. I guess that hardware integer division in processors became popular only when C was already widely in use.

Norbert Nemec:

> And it's the processor design that makes it inefficient to correct it nowadays.
>
> Python's definition of modulo is far more useful than C's. Implemented in machine code, however, it takes several additional commands because the integer division is hardwired to the C definition. I guess that hardware integer division in processors became popular only when C was already widely in use.

I see. Thank you for the explanations. So the situation isn't going to change soon.

Ada language offers both kind of modulus. I think std.math of Phobos should offer a mod() function that acts like the Python modulus.

Bye,
bearophile

On Saturday, 11 August 2012 at 17:15:21 UTC, Norbert Nemec wrote:
> On 11.08.2012 18:13, bearophile wrote:
>> David:
>>
>>> Thanks! I thought modulo should alawys yield the same ... seems like I
>>> was wrong ;)
>>
>> It's C design that's wrong.
>
> And it's the processor design that makes it inefficient to correct it nowadays.
>
> Python's definition of modulo is far more useful than C's. Implemented in machine code, however, it takes several additional commands because the integer division is hardwired to the C definition. I guess that hardware integer division in processors became popular only when C was already widely in use.

A few extra instructions (a CMOV followed by ADD should suffice, yes?) seems like a small price to pay if it can prevent bugs. Why hasn't the Python-modulo been made the default back when D was designed? The ever-so-slightly more efficient C-modulo could be provided in a library. Of course it's way too late to change it now...

I've asked for this before: http://www.digitalmars.com/d/archives/digitalmars/D/Could_we_have_mod_in_std.math_152977.html


On Sat, Aug 11, 2012 at 11:12 AM, bearophile <bearophileHUGS@lycos.com> wrote:
>
> It's a localized but important design bug of languages like C that D has carried over for backward compatibility reasons. D % has caused bugs in my code. I suggest to not use the built-in % on numbers that can be negative, unless you really know what you are doing.
>
> Bye,
> bearophile