Может ли целочисленное деление когда-либо переполняться или уменьшаться, если знаменатель ‹›0?

Может ли (истинное) целочисленное деление когда-либо переполняться или опускаться (при условии, что знаменатель не равен 0)?

Поскольку значение всегда либо остается неизменным, либо уменьшается (поскольку при целочисленном делении наименьший абсолютный ненулевой знаменатель равен 1, поэтому результат никогда не может быть больше числителя), я бы предположил, что нет.

Я спрашиваю более или менее в контексте стандартов C/C++, и меня интересует, как различные современные архитектуры ЦП могут по-разному обрабатывать целочисленное деление, когда речь идет об определенном/неопределенном поведении.


person Qix - MONICA WAS MISTREATED    schedule 15.11.2019    source источник
comment
Хе-хе, хороший улов @JimRhodes, прошла минута с тех пор, как я использовал этот термин.   -  person Qix - MONICA WAS MISTREATED    schedule 15.11.2019
comment
Кстати, <> должно быть !=   -  person pmg    schedule 15.11.2019
comment
@pmg <> традиционно означает больше/меньше; с цифрами это просто другое написание !=. Я использовал его больше для теоретических целей, а не для обозначения синтаксиса C.   -  person Qix - MONICA WAS MISTREATED    schedule 15.11.2019
comment
См. также переполнения при целочисленном делении.   -  person Steve Summit    schedule 16.11.2019
comment
Я бы сказал, что это дубликат :)   -  person Qix - MONICA WAS MISTREATED    schedule 16.11.2019


Ответы (1)


Поскольку значение всегда либо остается неизменным, либо уменьшается...

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

А поскольку знаменатель может быть отрицательным, есть один неясный, но губительный случай: в арифметике с дополнением до 2 математическим результатом INT_MIN / -1 является число, которое на единицу больше, чем INT_MAX.

То есть на 16-битной машине с дополнением до 2 INT_MIN равно −32768, что вполне представимо, но −32768 ÷ −1 должно быть равно +32768, а INT_MAX — всего лишь 32767. Аналогично, в 32-битном формате −2147483648 представимо, но тоже нельзя делить на −1.

Это своеобразная особенность арифметики дополнения до 2, возникающая из-за того, что величина INT_MIN не совсем такая же, как INT_MAX. С другой стороны, при арифметике дополнения или знака/величины INT_MIN является в точности отрицательным значением INT_MAX, поэтому здесь нет «разорительного случая», и, насколько я знаю, деление четко определено для всех входных данных (ну, за исключением нуля в знаменатель, разумеется).

person Steve Summit    schedule 15.11.2019
comment
хммм... больше INT_MAX на единицу не бывает :) - person pmg; 15.11.2019
comment
@pmg да, но так хочется ;) - person Patrick Roberts; 15.11.2019
comment
@pmg Смайли заметил, но ты прав. Скорректирована формулировка. - person Steve Summit; 15.11.2019
comment
И именно поэтому я до сих пор задаю такие, казалось бы, простые вопросы. Теперь очевидно, что вы указали на это. Спасибо :) - person Qix - MONICA WAS MISTREATED; 15.11.2019
comment
Просто для ясности: ..результатом оператора / является алгебраическое частное с отброшенной дробной частью.105) Если частное a/b представимо, выражение (a/b )*b + a%b равно a; в противном случае поведение как a/b, так и a%b не определено. port70.net/~nsz/c/c11/n1570.html#6.5.5p6 - person Eugene Sh.; 15.11.2019
comment
@ЕвгенийШ. в каком случае деление будет непредставимым, если его усечь? Это предложение никогда не имело для меня смысла (почему оно было бы неопределенным). - person Qix - MONICA WAS MISTREATED; 15.11.2019
comment
@Qix Если результат не соответствует типу - он непредставим. Он не усечен, он не определен. - person Eugene Sh.; 15.11.2019
comment
Ах, хорошо, правильно - это имеет смысл. - person Qix - MONICA WAS MISTREATED; 15.11.2019
comment
Если конкретная платформа реализует целочисленную арифметику, используя знак и величину вместо формы дополнения 2, этот губительный случай больше не будет применяться, поскольку INT_MIN и INT_MAX будут иметь одинаковую величину, верно? (Я знаю, что подавляющее большинство платформ используют форму дополнения 2, это всего лишь гипотетика) - person Patrick Roberts; 15.11.2019
comment
Интересно, что из той же цитаты мы можем сделать вывод, что INT_MIN % -1 тоже не определено, хотя в результате должно получиться 0. - person Eugene Sh.; 15.11.2019
comment
@ЕвгенийШ. Это интересно — спасибо, что указали на это. (Мне придется помнить об этом в следующий раз, когда я обновлю свою функцию преобразования десятичного числа в основание с отрицательным числом. :-)) - person Steve Summit; 15.11.2019
comment
@PatrickRoberts Я верю, что это правда. Ответ обновлен. - person Steve Summit; 15.11.2019
comment
@pmg Формулировка говорит, что есть число, которое на единицу больше, чем INT_MAX, что, безусловно, верно, и что это число является математическим результатом (а не результатом C). Это число/результат не может быть представлено в типе int. Абсолютно ничего плохого в используемом здесь языке. - person Kaz; 15.11.2019
comment
@Kaz Вы не видите формулировку, которую прокомментировал pmg. (Проверьте историю.) - person Steve Summit; 15.11.2019