OberonCore

Придирка к :
"Еще один пример. У нас есть 10 тонн мусора. Сколько требуется вывезти трехтонных грузовиков, чтобы всё отправить на свалку?
10 DIV (-3) = -4"
собственно такая:
(-10) DIV (-3) = 4
один грузовик обеспечивает убыль в (-3), а нужно (-10)

Согласен, может.
И я думал над Вашими примерами, но в них присутствует произвольность в выборе знака. В том же примере с мусором Вы приписываете его количеству положительный знак, но если он вывозится, то есть вычитается, то должен быть отрицательным.

Я смог найти целостность условий задачи с результатами при отрицательном делителе только в случае оперирования отрицательными объектами. Если не прибегать к помощи антивселенной, то отрицательный объект можно интерпретировать как свободное место, которое тоже имеет физический смысл и может заканчиваться по тем же законам, что и объекты. Это может быть что угодно: и количество столиков(+) со свободными(-) от посетителей местами, и атомы(+) со свободными(-) от электронов орбиталями.

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

Из-за отрицательных знаков точно есть вред, то что затрудняется понимание программы.

В книге:
Nikitin E.W. Into the Realm of Oberon. New York, NY: Springer New York, 1997.
нашел вот тоже упоминание этой проблемы

Хорошая ссылка, проясняющая позицию Вирта. Но я интепретировал неопределённость именно как ошибку времени исполнения или трансляции, потому что полагательство на платформоспецифическое поведение приводит к ошибкам на других платформах. Ошибкоустойчивый транслятор должен выявлять эту проблему, даже если на конкретной платформе это позволено и ожидаемо именно в таком виде.

В задаче с грузовиками знаки вообще не нужны. Точно такой же смысл получится, если ждать, пока грузовик привезёт 10 тонн, везде плюсы будут. А для оператора DIV задача будет звучать "сколько полных грузовиков..." и для MOD будет задача "сколько тонн останется", а то что вы там огругляете в рамках деления в разные стороны - ничем реальным материальным не обосновано.

Да, Пётр, логично рассудил. Без минусов будет понятнее и более предсказуемо. Так что еще и после книжки этой, склоняюсь к мнению, что смысл придумать для минусов возможно, но больше от этого проблем, чем достоинств.

Но тогда уж поправьте: 10 DIV 3 всё ж таки 3, а то арифметикой за 4-й класс повеяло

Справедливости ради, надо заметить, что спор только про отрицательный числитель/знаменатель.

По честному будет ввести арифметический и экономический операторы, тогда все будут довольны. Я бы ещё упомянул то, что в обероне сдвиги арифметические, а логические только в модуле SYSTEM, тоже спорный момент

10 DIV (-3) = -4
Так в Обероне и в Компонентном Паскале, так что поправлять нечего. Компонентный Паскаль точно никто править не собирается ближайшее время

В Обероне не так, на предыдущей странице было же.

Попытка проверить ваше утверждение в XDS привело к интересному наблюдению



В XDS запрещен делитель меньше нуля при целочисленном делении.
shall not have a value less than 0



В Онлайн компиляторе действительно получается -3
https://models.molpit.org/model/134

Проверил как во время исполнения обрабатывается ошибка.


Он еще на этапе компиляции сказал, что ошибка во время исполнения будет, но разрешил собрать программу.


Как компилятор предупреждал, сработала обработка исключения во время выполнения:

В OFront воплощение функции деления было сделано с ошибками. Они остаются в OFront+ и в voc

При условии ( (x < 0) # (y < 0) ) & ( ABS(x) > MAX(LONGINT) - ABS(y) ) будет переполнение несмотря на допустимые для деления входные параметры. Согласно стандарту Си переполнение целых чисел со знаком является неопределённым поведением, что не позволяет предсказать поведение программы для общего случая - возможна и аварийная остановка. При использовании флага компилятора -fwrapv в gcc и clang переполнение будет проводится в соответствии с машинными вычислениями в дополнительном коде. Но и тогда результат во многих случаях будет некорректным.
Также, из-за дополнительного кода будет выполняться некорректное равенство MIN(LONGINT) DIV (-1) = MIN(LONGINT) . clang для такого деления может сгенерировать аварийное завершение несмотря на флаг -fwrapv, что можно рассматривать как преимущество для диагностики.

В CPFront нет проблемы с переполнением
Ещё одним преимуществом этого варианта в том, что в нём явная проверка деления на 0. В Си полагаться на то, что при делении на 0 произойдёт аварийная остановка в общем случае нельзя, потому что это тоже неопределённое поведение. Тем не менее, в решении для КП тоже есть проблема с делением минимального значения на -1, а трюки с побитовым отрицанием жёстко завязаны на дополнительный код.

Предложите корректное решение, внесём правки.

1. Побитовое отрицание эквивалентно вычитанию из -1.
2. Нельзя просто так менять знак отрицательного числа
2.1. Либо проверять на возможность переполнения при MIN(INTEGER)
2.2. Либо переписать так, чтобы отпала необходимость в смене знака
3. При отрицательных делимом и делителе нужно проверять на совпадение значений MIN(INTEGER) и -1

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

Мне было интереснее проверить практически, как это реализовано. И тут к тому же написано, что только для положительного делителя определены эти формулы. Так что вопрос отрицательного делителя описанием языка не определен в этом фрагменте документации.

Как в Аде, да. Две операции: rem (remainder) и mod (modulus). Первая определена согласно правилу A = (A/B)*B + (A rem B), вторая - A = B*N + (A mod B) для некоторого N. Иначе говоря, rem сохраняет знак делимого, а mod - делителя. И обычно таки нужен rem, а не mod.

P.S. В C, кстати, по крайней мере в С99, поведение % в этом отношении вообще implementation specific.

В С89, но не в С99, где это определено конкретно.

Ошибся, да. В С99 таки уже чётенько "truncation toward zero". Ну, не суть. А две разных операции есть ещё, как минимум, в Fortran и всякой "функцианальщине" типа там Scheme, Haskell.