Деление на 0

@viramir · Регистрация: 04.05.2016

Студворк — интернет-сервис помощи студентам

Все говорят на 0 делить нельзя,но я поделил,в чем тут подвох

C++
1
2
3
4
5
6
7
8
9
#include <iostream>
 
using namespace std;
 
int main()
{
int x=1/(double)0;
cout<<x<<endl;
}

и получился результат -2147483648

Evg · 29.03.2018, 21:11

Нету такого типа "long long double". Есть "long long", и есть "long double". Что конкретно ты имел в виду?

C++
#include <iostream>
 
using namespace std;
 
int main()
{
long long x=1/(double)0;
cout<<x<<endl;
 
long double y=1/(double)0;
cout<<y<<endl;
}

Code
$ g++ t.cc
$ ./a.exe
-9223372036854775808
inf

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

Сообщение от viramir

результат всегда INT

Если под словом INT ты имел в виду "inf" в печати, то "inf" это и есть бесконечность (infinity по английски)

@viramir · 29.03.2018, 21:12 **[ТС]**

Evg, перепутал long long int
и бесконечность я имел в виду

@Mournful Max · 29.03.2018, 22:47

Evg уже все рассказал и показал. Добавлю только вырезку из Стандарта:

If the second operand of / or % is zero the behavior is undefined.

Evg · 29.03.2018, 23:12

Captain Maxee, видимо, это вырезка по части целочисленного деления. А тут речь идёт о вещественном делении

@Mournful Max · 30.03.2018, 00:48

Evg, нет. Это касается и вещественного деления

@woldemas · 30.03.2018, 04:04

Сообщение от Captain Maxee

Это касается и вещественного деления

Да не может такого быть!
А как же IEEE 754 ?

@Mournful Max · 30.03.2018, 04:42

Сообщение от woldemas

А как же IEEE 754 ?

А кто дает гарантии, что именно это представление будет использоваться?

@woldemas · 30.03.2018, 07:03

Сообщение от Captain Maxee

А кто дает гарантии, что именно это представление будет использоваться?

Да вроде как производители процессоров intel, AMD - вот эти ребята.
Хотя я не специалист, но во многих реальных программах связанных с вычислениями, вещественное деление на ноль используется, видел то ли в OpenCV, то ли в OpenCASCAD. Например, если в знаменателе разность вещественных чисел, а в числителе - ненулевое число, делят не проверяя, а результат используется для сравнения с каким-то значением, бесконечность всегда будет больше, минус бесконечность меньше.

@Mournful Max · 30.03.2018, 08:40

Сообщение от woldemas

intel, AMD - вот эти ребята.

Что насчет ребят из IBM..?

Понимаете к чему я клоню? Очевидно, что большинство современных процессоров сейчас используют именно IEEE 754, но все же не все. Это не единственный стандарт представления вещественных чисел... существуют другие. Именно поэтому в Стандарте, что касается математических констант ( INFINITY или NAN, к примеру ), приставляется фраза «if available».
Я не хотел сейчас этим выпендриться. Я Вас уважаю. Просто поставил остальных в известность. Я считаю, что это полезная информация.

Evg · 30.03.2018, 09:14

Посмотрел в стандарт ISO/IEC 9899:1999, действительно в разделе 6.5.5 пункт 5 про деление говорится в целом, не разделяя на целочисленное и вещественное. Однако постфактум имеем то, что это является очередным местом, где в реальной жизни поведение в данном месте почти всегда можно считать вполне определённым. Постфактум на всех культурных процессорах вещественные вычисления работают в стандарте IEEE-754 в части float и double и в аналогичных по свойству стандартах для long double

Вырезку из стандарта, приведённую в посте #23, следует трактовать как общее замечание, напрямую не относящееся к данной теме. Просто об этом лучше писать явно, а то многие начинающие прочтут, не так поймут, и начнут делать очередные бредовые заявления типа того, что написано в посте #14

Несмотря на то, что все железки работают более-менее одинаково, мы всё равно имеем некие тонкие отличия, которые я описал в посте #13. В ситуациях, которые не покрыты стандартом IEEE-754 (или там обозначены как-нибудь со смыслом implementation defined) мы имеем различное поведение одного и того же кода на разных процессорах. Т.е. расслабляться раньше времени не следует. Лучше взять за правило и максимально избегать любой ситуации, не имеющей однозначной трактовки в стандарте Си

ValeryS · 30.03.2018, 09:25

Сообщение от viramir

Все говорят на 0 делить нельзя,

"а я говорю что буду"(с)

Сообщение от viramir

и получился результат -2147483648

а в шестнадцатеричном виде ? 0xFFFFFFFF
это и есть INF для double, точнее часть его полный INF 0xFFFFFFFFFFFFFFFF
но все остальное уже сказали

Сообщение от viramir

C++
1
2
3
4
5
float f1 = 1.2345;
double f2 = 1.2345;
.....
  if (f1 == f2)
    printf ("equal\n");

а так

Evg · 30.03.2018, 09:37

Сообщение от ValeryS

а в шестнадцатеричном виде ? 0xFFFFFFFF

Нет. 0x10000000

Не говоря уж о том, что на sparc'е совсем другое значение

Сообщение от ValeryS

это и есть INF для double, точнее часть его полный INF 0xFFFFFFFFFFFFFFFF

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

Когда преобразуют из вещественного в целое, то если вещественное имеет значение больше, чем максимально возможное целое, то одно из решений - в качестве результата получить максимально возможное целое (это называется "преобразование с насыщением результата"). Именно по такой логике работает sparc'овская железка. Т.е. преобразование вещественной бесконечности в 32-битное целое даёт значение +2147483647. На интеле по каким-то своим внутренним соображениям результат получается на единицу больше, что превращается в -2147483648

Но ни то, ни другое, вообще никак не связаны с битовым представлением бесконечности, которое к тому же ты ещё и неправильно расписал. Бесконечность имеет все единички в экспоненте и все нули в мантиссе. Ну ещё знак. Т.е. double'овый +inf в битовом представлении выглядит как 0x7fff000000000000

Добавлено через 1 минуту

Не по теме:

Сообщение от ValeryS

а так

Очевидно, к делу не относится. Код из поста #15 является контрпримером

ValeryS · 30.03.2018, 09:55

Сообщение от Evg

Очевидно, к делу не относится.

Ну я же смайлик поставил

Сообщение от Evg

Бесконечность имеет все единички в экспоненте и все нули в мантиссе.

спасибо, давно не заглядывал в документацию, помню только что невозможное число

Evg · 30.03.2018, 15:07

Не по теме:

Сообщение от ValeryS

Ну я же смайлик поставил

Да я понял, но написал на всякий случай (потому и в оффтоп). А то мало ли кто-то не поймёт и начнёт срач

Новые блоги и статьи Все статьи Все блоги /
Модель микоризы: классовый агентный подход 3 anaschu 06.01.2026 aa0a7f55b50dd51c5ec569d2d10c54f6/ O1rJuneU_ls https:/ / vkvideo. ru/ video-115721503_456239114	Owen Logic: О недопустимости использования связки «аналоговый ПИД» + RegKZR ФедосеевПавел 06.01.2026 Owen Logic: О недопустимости использования связки «аналоговый ПИД» + RegKZR ВВЕДЕНИЕ Введу сокращения: аналоговый ПИД — ПИД регулятор с управляющим выходом в виде числа в диапазоне от 0% до. . .	Модель микоризы: классовый агентный подход 2 anaschu 06.01.2026 репозиторий https:/ / github. com/ shumilovas/ fungi ветка по-частям. коммит Create переделка под биомассу. txt вход sc, но sm считается внутри мицелия. кстати, обьем тоже должен там считаться. . . .	Расчёт токов в цепи постоянного тока igorrr37 05.01.2026 / * Дана цепь постоянного тока с сопротивлениями и напряжениями. Надо найти токи в ветвях. Программа составляет систему уравнений по 1 и 2 законам Кирхгофа и решает её. Последовательность действий:. . .
Новый CodeBlocs. Версия 25.03 palva 04.01.2026 Оказывается, недавно вышла новая версия CodeBlocks за номером 25. 03. Когда-то давно я возился с только что вышедшей тогда версией 20. 03. С тех пор я давно снёс всё с компьютера и забыл. Теперь. . .	Модель микоризы: классовый агентный подход anaschu 02.01.2026 Раньше это было два гриба и бактерия. Теперь три гриба, растение. И на уровне агентов добавится между грибами или бактериями взаимодействий. До того я пробовал подход через многомерные массивы,. . .	Советы по крайней бережливости. Внимание, это ОЧЕНЬ длинный пост. Programma_Boinc 28.12.2025 Советы по крайней бережливости. Внимание, это ОЧЕНЬ длинный пост. Налог на собак: https:/ / ********/ gallery/ V06K53e Финансовый отчет в Excel: https:/ / ********/ gallery/ bKBkQFf Пост отсюда. . .	Кто-нибудь знает, где можно бесплатно получить настольный компьютер или ноутбук? США. Programma_Boinc 26.12.2025 Нашел на реддите интересную статью под названием Anyone know where to get a free Desktop or Laptop? Ниже её машинный перевод. После долгих разбирательств я наконец-то вернула себе. . .

@viramir 1 / 1 / 1 Регистрация: 04.05.2016 Сообщений: 266
	29.03.2018, 21:12 [ТС]
	Evg, перепутал long long int и бесконечность я имел в виду 0

Evg 21281 / 8305 / 637 Регистрация: 30.03.2009 Сообщений: 22,660 Записей в блоге: 30
	29.03.2018, 23:12
	Captain Maxee, видимо, это вырезка по части целочисленного деления. А тут речь идёт о вещественном делении 0

@Mournful Max Велосипедист... 353 / 220 / 73 Регистрация: 15.12.2015 Сообщений: 785
	30.03.2018, 00:48
	Evg, нет. Это касается и вещественного деления 1

Evg 21281 / 8305 / 637 Регистрация: 30.03.2009 Сообщений: 22,660 Записей в блоге: 30
	30.03.2018, 09:14
	Посмотрел в стандарт ISO/IEC 9899:1999, действительно в разделе 6.5.5 пункт 5 про деление говорится в целом, не разделяя на целочисленное и вещественное. Однако постфактум имеем то, что это является очередным местом, где в реальной жизни поведение в данном месте почти всегда можно считать вполне определённым. Постфактум на всех культурных процессорах вещественные вычисления работают в стандарте IEEE-754 в части float и double и в аналогичных по свойству стандартах для long double Вырезку из стандарта, приведённую в посте #23, следует трактовать как общее замечание, напрямую не относящееся к данной теме. Просто об этом лучше писать явно, а то многие начинающие прочтут, не так поймут, и начнут делать очередные бредовые заявления типа того, что написано в посте #14 Несмотря на то, что все железки работают более-менее одинаково, мы всё равно имеем некие тонкие отличия, которые я описал в посте #13. В ситуациях, которые не покрыты стандартом IEEE-754 (или там обозначены как-нибудь со смыслом implementation defined) мы имеем различное поведение одного и того же кода на разных процессорах. Т.е. расслабляться раньше времени не следует. Лучше взять за правило и максимально избегать любой ситуации, не имеющей однозначной трактовки в стандарте Си 1