IEEE754

[ozheredov]

KrisMarka в сообщении #1419363 писал(а):

Значит ли это, что, если мы знаем, сколько получится, то на нуль все-таки можно делить?

Одинаковое количество "нуля" вмещается и в шестерку, и триллионку. Поэтому бесконечность -- это не число в обычном смысле, хотя многие компьютерные системы допускают бесконечность как объект с некоторыми методами, в числе которых оператор

*

:

6 / 0 = Inf, 42 / 0 = Inf

А если теперь "проверить" результат умножением?

Inf * 0 = NaN

Получили объект нового типа -- Not a Number. То есть если аккуратно ввести оператор деления, дополнив числа двумя объектами -- Inf и NaN -- то делить на ноль можно. Ни в коем случае нельзя делить на очень маленькое число с т.зрения компа, но это уже совсем другая история )

[ewert]

ozheredov в сообщении #1419389 писал(а):

если аккуратно ввести оператор деления, дополнив числа двумя объектами -- Inf и NaN -- то делить на ноль можно.

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

[Sonic86]

ozheredov в сообщении #1419389 писал(а):

Получили объект нового типа -- Not a Number. То есть если аккуратно ввести оператор деления, дополнив числа двумя объектами -- Inf и NaN -- то делить на ноль можно.

Почему программисты никак не могут понять, что если у них в ЯП как-то определен Inf, NaN, то не надо его совать во все дыры и демонстрировать подобное непотребство, а сидеть дома вместе со своим Inf-NaNом и никому его не показывать. (а если их слушать, то они еще расскажут, что null не равно null и прочие сказочки)

Ответы кратко:
$0$ делится на $0$, по определению. ($0=1\cdot 0, \ 0=2\cdot 0, ...$)
Частное $0:0$ не определено.
Для $a\neq 0$ величина $a:0$ не определена в кольце целых чисел по сложению и умножению, а также в любом другом кольце, содержащем кольцо целых чисел (по этой причине мнение программистов следует выбросить в мусорку). Если дополнить кольцо целых чисел элементом $z$ таким, что $z=0:0$, то нарушится как минимум дистрибутивность кольца.

Someone в сообщении #941039 писал(а):

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

[arseniiv]

ozheredov
Надо понимать, что стандарт IEEE 754 — не какой-то абсолют, а имеет свои причины, многие из которых весьма специфичны. (И что это не единственный способ организовать даже плавающую точку, не говоря уже о вообще представлении чего-то, достаточно похожего на вещественные/рациональные числа.) И там например даже сложение не ассоциативно. Потому вы с большой вероятностью запутали ТС (и остальных читателей того же уровня).

Я тоже хотел писать ответ про то, что будет, если вводить результатом деления не обычное число (потому что про невозможность сделать им обычное написано по ссылке на Элементы), но в теме по второй ссылке это всё тоже разобрано, а именно что первейшая причина, если мы вводим обратный для нуля — нарушение $0\cdot x = 0$, которое выводится с помощью таких-то и таких-то вещей, хотя бы одной из которых нам надо будет пожертвовать, а все они довольно хороши.

[Munin]

arseniiv в сообщении #1419403 писал(а):

стандарт IEEE 754 — не какой-то абсолют

Не покушайтесь на святое! :-)

[arseniiv]

Вполне возможно, в будущем ему будет конкурент, есть кандидаты.

[Xugin]

А что на самом деле в памяти получится если обойти запрет деления на ноль или превышения значения самых тяжеловесных числовых форматов?

[arseniiv]

Xugin
Деление вообще реализуемо разными алгоритмами. Какой-то может зациклиться, какой-то без явных отдельных проверок делителя на равенство нулю всё равно выдаст результат.

Например простейший «вычитательный» алгоритм

m := делимое; n := делитель; r := 0
while m ≥ n:
    m := m - n
    r := r + 1
return r

зациклится.

И всё зависит от того, какие операции мы считаем предзаданными. (Деление и целых, и чисел с плавающей точкой (разумных небольших длин) на многих процессорах для ПК — отдельная операция, и разумеется не реализуется программно. А вот на RISC-микроконтроллерах обычно наоборот.)

Xugin в сообщении #1419458 писал(а):

или превышения значения самых тяжеловесных числовых форматов

Что конкретно имеется в виду? Что получится, если результат больше, чем представимые значения? Зависит от формата или от спецификации операций, если она каким-то чудом не входит в описание формата. В IEEE 754 в одном случае получится $\pm\infty$, но может быть вызвана и ошибка (вот тут я плохо знаю детали). Спецификация может и обходить это стороной, и разные её конкретные реализации могут тогда вполне законно расходиться в том, что делают.

-- Вс окт 06, 2019 23:44:47 --

UPD. Дописал в середину.

[ozheredov]

ewert в сообщении #1419397 писал(а):

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

И-иии? Дистрибутивность это обычное свойство операторов, которое где-то нужно, где-то нет.

Sonic86 в сообщении #1419400 писал(а):

Почему программисты никак не могут понять, что если у них в ЯП как-то определен Inf, NaN, то не надо его совать во все дыры и демонстрировать подобное непотребство, а сидеть дома вместе со своим Inf-NaNом и никому его не показывать.

Вы хотите, чтобы деление на ноль приводило к аварийному завершению всего и вся? Inf и NaN это грубо говоря та же обработка исключений, только впрофиль красиво и непринужденно.

Sonic86 в сообщении #1419400 писал(а):

Ответы кратко:
$0$ делится на $0$, по определению.

Если определение мешает практически полезным реализациям -- ф топку определение, вслед за дистрибутивностью.

arseniiv в сообщении #1419403 писал(а):

И там например даже сложение не ассоциативно

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

[arseniiv]

ozheredov в сообщении #1419768 писал(а):

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

В некоторых. А в других приходится городить огород в низкоуровневых численных алгоритмах, чтобы они не так сильно мешались под ногами. Складывать в определённом порядке и т. п.. А тут тема более универсальная, это как обсуждение интерфейса, а не какой-то его реализации (при том, что фактически реализация не совсем и реализация; достаточно строгий и мощный (чтобы это увидеть) компилятор за такое голову оторвёт).

ozheredov в сообщении #1419768 писал(а):

Вы хотите, чтобы деление на ноль приводило к аварийному завершению всего и вся?

Думаю, ничего такого Sonic86 не хочет и просто написал, что вы пришли объяснять математику практикой программирования, конкретнее даже отдельным стандартом IEEE 754, не единственным возможным. И притом позволяющим вызывать (в другом режиме) вместо генерации Inf и NaN ошибки, да. Высокоуровневые языки часто не дают возможности выбрать, ой.

ozheredov в сообщении #1419768 писал(а):

Если определение мешает практически полезным реализациям -- ф топку определение, вслед за дистрибутивностью.

Это вы зря, определение делимости на моей памяти ничему не мешало.

[ozheredov]

arseniiv в сообщении #1419771 писал(а):

вы пришли объяснять математику практикой программирования

Вот это как раз принципиальный для меня момент, поэтому я и подорвался ) С моей т.зрения, программирование -- естественный (и единственный) работодатель математики, и последняя должна подстраиваться под его нужды и парадигмы.

UPD: еще есть подсчет сдачи на рынке физика, но физика сейчас это на 99.99999% моделирование, а моделирование это...

[arseniiv]

ozheredov в сообщении #1419774 писал(а):

С моей т.зрения, программирование -- естественный (и единственный) работодатель математики, и последняя должна подстраиваться под его нужды и парадигмы.

А как же физика, химия?.. Остальная прикладная математика началась задолго до программирования и с его появлением не умерла. Кроме того у программирования нужды тоже разные.

ozheredov в сообщении #1419774 писал(а):

а моделирование это...

Проработанные численные методы и понимание, когда например решение блоуапится. Вот что получается если делать как попало:

(это я сам и сделал лет пять назад; потом мне насоветовали хорошего, но лень было доделывать).

[vpb]

ozheredov в сообщении #1419774 писал(а):

С моей т.зрения, программирование -- естественный (и единственный) работодатель математики, и последняя должна подстраиваться под его нужды и парадигмы.

Совершенно не так. Наоборот, компьютеры и программирование были придуманы прикладными математиками и физиками для того, чтоб решать ихние задачи. Думаю, и сейчас самая важная роль компьютеров и программирования примерно та же самая. А возможность смотреть всякую дребедень по ютубу и пулять стрелялки --- не более чем побочный продукт.

[oleg.k]

ewert в сообщении #1419397 писал(а):

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

Интересно, а всегда ли дистрибутивность так необходима? Существуют ли какие-нибудь полезные структуры (где определено деление на нейтральный элемент по сложению), которые можно применять для решения задач, традиционно решаемых с помощью $\mathbb{R}$? Свет ведь клином на $\mathbb{R}$ не сошелся. Ближайший пример приношения в жертву - $\mathbb{C}$. Да, порядком пожертвовали. Но получили массу полезностей. Чем дистрибутивность лучше порядка? Было бы интересно узнать про такие структуры с делением на ноль.

[Geen]

oleg.k в сообщении #1419798 писал(а):

Чем дистрибутивность лучше порядка?

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