4 ms·

Changing well known behavior for something no one is really going to need. The justification makes sense, but it breaks convention and the relationship with mod

by z_open 3y ago

Changing well known behavior for something no one is really going to need. The justification makes sense, but it breaks convention and the relationship with modulo doesn't need to hold for negative numbers.

lifthrasiir 3y ago
Quantify "well known". Historically enough variation existed in this area [1], and C only happened to copy FORTRAN's behavior for the sake of compatibility. [1] https://en.wikipedia.org/wiki/Modulo#In_programming_languages https://en.wikipedia.org/wiki/Modulo#In_programming_language...
- BlueTemplar 3y ago
  Python does follow the convention, but what I am wondering now is why did FORTRAN break it ?
  - asplake 3y ago
    Fortran is old – 1958 onwards. It has precedence here, though at what point it separated the two behaviours into mod and modulo functions I don’t know. Edit: From what I can tell, standardised in Fortran 90, presumably older than that.
    - BlueTemplar 3y ago
      My point is that Fortran doesn't have precedence on math, see this comment by Austin Feller : http://python-history.blogspot.com/2010/08/why-pythons-integer-division-floors.html?showComment=1404050838672#c3832102777815381946 http://python-history.blogspot.com/2010/08/why-pythons-integ...
  - wombatpm 3y ago
    Maybe because FORTRAN arrays index from 1 by default?
Skeime 3y ago
I strongly disagree. I would estimate that in 90% of cases where I use modulo in languages that truncate (instead of flooring), I write (a % b + b) % b, or something similar, just to get the right behaviour. The exceptional cases are those where I can convince myself that negative numbers simply won't come up. (It's never because I actually want the other behaviour for negative numbers.) - When using modulo to access an array cyclically. (You might get lucky that your language allows using negative numbers to index from the back. In that case, both conventions work.) - When lowering the resolution of integers. If you round to zero, you get strange artifacts around zero, because -b+1, ..., -1, 0, 1, ..., b-1 all go to zero when dividing by b. That's 2b-1 numbers. For every other integer k, there are only b numbers (namely bk, bk+1, ..., bk+b-1). I have never seen a case where truncation was the right thing to do. (When dealing with integers. Floats are different, of course, but they are not what this is about.)
- ncruces 3y ago
  Very much this.
- cygx 3y ago
  A common approach (e.g. Cobol, Ada, Common Lisp, Haskell, Clojure, MATLAB, Julia, Kotlin) seems to be to provide two operators: One that uses truncated division, one that uses floored division. By convention, rem truncates, and mod floors.
  - TheRealKing 3y ago
    And first of all, Fortran.
- pwdisswordfishc 3y ago
  > I have never seen a case where truncation was the right thing to do. Splitting a quantity into units of differing orders of magnitude. For example, −144 minutes is −2 hours and −24 minutes, not −3 hours and 36 minutes. This is about the only case I know of, though.
  - 3y ago
ReleaseCandidat 3y ago
> Changing well known behavior for something no one is really going to need. On the contrary I can't imagine when and why anybody would want truncation. That's just a side effect of the used algorithm and not something that actually makes much (any?) sense.
- kragen 3y ago
  the post gives two examples: - given a number t of seconds after the epoch, what time of day does it represent? using python's definition, (t + tz) % 86400 - given an offset d between two pixels in a pixel buffer organized into sequential lines, what is the x component of the offset? using python's definition, d % width is right when the answer is positive, width - (d % width) when the answer is negative, so you could write d % width - d > p0x ? d % width : width - d % width. this gets more complicated with the fortran definition, not simpler edit: the correct expression is (d % width if p0x + d % width < width else d % width - width) or in c-like syntax (p0x + d % width < width ? d % width : d % width - width). see http://canonical.org/~kragen/sw/dev3/modpix.py http://canonical.org/~kragen/sw/dev3/modpix.py
pwdisswordfishc 3y ago
> the relationship with modulo doesn't need to hold for negative numbers. It especially needs to hold, given how often overlooked negative numbers are when reasoning about programs.

by z_open 3y ago

lifthrasiir 3y ago

Quantify "well known". Historically enough variation existed in this area [1], and C only happened to copy FORTRAN's behavior for the sake of compatibility. [1] https://en.wikipedia.org/wiki/Modulo#In_programming_languages https://en.wikipedia.org/wiki/Modulo#In_programming_language...

BlueTemplar 3y ago
Python does follow the convention, but what I am wondering now is why did FORTRAN break it ?
- asplake 3y ago
  Fortran is old – 1958 onwards. It has precedence here, though at what point it separated the two behaviours into mod and modulo functions I don’t know. Edit: From what I can tell, standardised in Fortran 90, presumably older than that.
  - BlueTemplar 3y ago
    My point is that Fortran doesn't have precedence on math, see this comment by Austin Feller : http://python-history.blogspot.com/2010/08/why-pythons-integer-division-floors.html?showComment=1404050838672#c3832102777815381946 http://python-history.blogspot.com/2010/08/why-pythons-integ...
- wombatpm 3y ago
  Maybe because FORTRAN arrays index from 1 by default?

Skeime 3y ago

I strongly disagree. I would estimate that in 90% of cases where I use modulo in languages that truncate (instead of flooring), I write (a % b + b) % b, or something similar, just to get the right behaviour. The exceptional cases are those where I can convince myself that negative numbers simply won't come up. (It's never because I actually want the other behaviour for negative numbers.) - When using modulo to access an array cyclically. (You might get lucky that your language allows using negative numbers to index from the back. In that case, both conventions work.) - When lowering the resolution of integers. If you round to zero, you get strange artifacts around zero, because -b+1, ..., -1, 0, 1, ..., b-1 all go to zero when dividing by b. That's 2b-1 numbers. For every other integer k, there are only b numbers (namely bk, bk+1, ..., bk+b-1). I have never seen a case where truncation was the right thing to do. (When dealing with integers. Floats are different, of course, but they are not what this is about.)

ncruces 3y ago
Very much this.
cygx 3y ago
A common approach (e.g. Cobol, Ada, Common Lisp, Haskell, Clojure, MATLAB, Julia, Kotlin) seems to be to provide two operators: One that uses truncated division, one that uses floored division. By convention, rem truncates, and mod floors.
- TheRealKing 3y ago
  And first of all, Fortran.
pwdisswordfishc 3y ago
> I have never seen a case where truncation was the right thing to do. Splitting a quantity into units of differing orders of magnitude. For example, −144 minutes is −2 hours and −24 minutes, not −3 hours and 36 minutes. This is about the only case I know of, though.
- 3y ago

ReleaseCandidat 3y ago

> Changing well known behavior for something no one is really going to need. On the contrary I can't imagine when and why anybody would want truncation. That's just a side effect of the used algorithm and not something that actually makes much (any?) sense.

kragen 3y ago
the post gives two examples: - given a number t of seconds after the epoch, what time of day does it represent? using python's definition, (t + tz) % 86400 - given an offset d between two pixels in a pixel buffer organized into sequential lines, what is the x component of the offset? using python's definition, d % width is right when the answer is positive, width - (d % width) when the answer is negative, so you could write d % width - d > p0x ? d % width : width - d % width. this gets more complicated with the fortran definition, not simpler edit: the correct expression is (d % width if p0x + d % width < width else d % width - width) or in c-like syntax (p0x + d % width < width ? d % width : d % width - width). see http://canonical.org/~kragen/sw/dev3/modpix.py http://canonical.org/~kragen/sw/dev3/modpix.py

pwdisswordfishc 3y ago

> the relationship with modulo doesn't need to hold for negative numbers. It especially needs to hold, given how often overlooked negative numbers are when reasoning about programs.