Почему целочисленное деление округляется во многих языках сценариев?

В идеале мы хотели бы иметь две операции div и mod, удовлетворяющие для каждой b>0:

1. (a div b) * b + (a mod b) = a
2. 0 <= (a mod b) < b
3. (-a) div b = -(a div b)

Это, однако, математическая невозможность. Если бы все вышесказанное было правдой, мы бы

1 div 2 = 0
1 mod 2 = 1

Так как это единственное целочисленное решение для (1) и (2). Следовательно, мы также имели бы, по (3),

0 = -0 = -(1 div 2) = (-1) div 2

Что, согласно (1), подразумевает

-1 = ((-1) div 2) * 2 + ((-1) mod 2) = 0 * 2 + ((-1) mod 2) = (-1) mod 2

Создание (-1) mod 2 < 0, которое противоречит (2).

Следовательно, нам нужно отказаться от некоторого свойства среди (1), (2) и (3).

Некоторые языки программирования отказываются от (3) и делают div округление вниз (Python, Ruby).

В некоторых (редких) случаях язык предлагает несколько операторов деления. Например, в Haskell мы имеем div,mod, удовлетворяющие только (1) и (2), подобно Python, и мы также имеем quot,rem, удовлетворяющие только (1) и (3). Последняя пара операторов округляет деление до нуля , по цене возвращая отрицательные остатки, например, мы имеем (-1) `quot` 2 = 0 и (-1) `rem` 2 = (-1).

C# также отказывается от (2) и позволяет % вернуть отрицательный остаток. Когерентно, целочисленное деление округляется до нуля. Java, Scala, Pascal и C, начиная с C99, также принимают эту стратегию.

Потому что смысл целочисленного деления состоит в том, что полный ответ включает остаток.

В Википедии есть большая статья об этом , включая историю, а также теорию.

---

До тех пор, пока язык удовлетворяет свойству евклидова деления, что (a/b) * b + (a%b) == a, и напольное деление, и усекающее деление когерентны и арифметически разумны.

---

Конечно, люди любят спорить о том, что одно очевидно правильно, а другое очевидно неправильно, но это больше похоже на священную войну, чем на разумную дискуссию, и обычно это имеет больше отношения к делу. с выбором их раннего предпочтительного языка, чем что-либо другое. Они также часто склонны спорить в первую очередь за свою избранную %, хотя, вероятно, имеет больше смысла сначала выбрать /, а затем просто выбрать %, который соответствует.

• настил (как питон):
  Не меньший авторитет, чем Дональд Кнут, предлагает это.
• % следование знаку делителя-это, по-видимому, то, о чем догадываются около 70% всех студентов
• оператор обычно читается как mod или modulo вместо remainder.
• "C делает это"-что даже не верно.¹

усечение (как C++):

• делает целочисленное деление более согласованным с IEEE float division (в режиме округления по умолчанию).
• его реализуют другие процессоры. (Возможно, это не так в разные периоды истории.)
• оператор читается modulo, а не remainder (хотя это фактически доказываетпротив их точки зрения).
• свойство разделения концептуально это больше остаток, чем модуль.
• оператор читается mod, а не modulo, поэтому он должен следовать различию Фортрана. (Это может показаться глупым, но, возможно, было решающим фактором для C99. Смотрите эту нить.)

"Евклидово" (подобно Паскалю-/ этажи или усечения в зависимости от знаков, поэтому % никогда не бывает отрицательным):

Никлаус Вирт утверждал, что никто никогда не удивляется позитиву mod.

Раймонд т. Бут позже утверждал: что вы не можете реализовать евклидово деление наивно ни с одним из других правил.

Ряд языков обеспечивает и то, и другое. Обычно-как Ада, Модула-2, немного шепелявит, Хаскелл, и Юля-они используют имена, связанные с mod Для в стиле Python оператор и rem для C++-стиле оператора. Но не всегда-Фортран, например, называет одни и те же вещи modulo и mod (Как упоминалось выше для C99).

---

Мы не знаем, почему Python, Tcl, Perl и другие влиятельные скриптовые языки в основном выбирали напольное покрытие. Как отмечалось в вопросе, ответ Гвидо ван Россума объясняет только то, почему он должен был выбрать один из трех последовательных ответов, а не то, почему он выбрал тот, который он сделал.

Однако я подозреваю, что влияние С было ключевым. Большинство скриптовых языков (по крайней мере, изначально) реализованы на языке C, и заимствование их операторного инвентаря из реализации C. C89-defined % явно нарушено и не подходит для "дружественного" языка, такого как Tcl или Питон. И C вызывает оператора "mod". Поэтому они идут с модулем, а не остатком.

---

_{1. Несмотря на то, что вопрос Говорит-и многие люди используют его в качестве аргумента-C на самом деле не имеет сходного поведения с Python и друзьями. C99 требует усечения деления,а не настила. C89 разрешил либо, а также разрешил любую версию mod, так что нет никакой гарантии свойства division, и нет способа написать переносимый код, делающий знаковое целочисленное деление. Это просто ... сломанный.}

Как сказала Паула, это из-за остатка.

Алгоритм основан наевклидовом делении .

В Ruby вы можете написать это перестроение дивидендов с последовательностью:

puts (10/3)*3 + 10%3
#=> 10

То же самое происходит и в реальной жизни. 10 яблок и 3 человека. Хорошо, вы можете разрезать одно яблоко на три, но выходя за пределы заданных целых чисел.

С отрицательными числами также сохраняется последовательность:

puts (-10/3)*3 + -10%3 #=> -10
puts (10/(-3))*(-3) + 10%(-3) #=> 10
puts (-10/(-3))*(-3) + -10%(-3) #=> -10

Частное всегда округлено вниз (вниз вдоль отрицательной оси) и ниже следует напоминание:

puts (-10/3) #=> -4
puts -10%3 #=> 2

puts (10/(-3)) #=> -4
puts 10%(-3) # => -2

puts (-10/(-3)) #=> 3
puts -10%(-3) #=> -1