Деление на 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

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

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

Новые блоги и статьи Все статьи Все блоги /
Программа для com-порта Uhbif79 05.06.2026 Всем привет, давно хотел изучить Qt, начинал, бросал, потом снова начинал. И сейчас вот смог написать свою первую программу. До этого имел опыт программирования микроконтроллеров, писал прошивки на. . .	Транскрипция 55-минутного видео через Whisper: WhisperDesktop облажался, спас Google Colab[ anaschu 01.06.2026 Понадобилось получить текст из свежезагруженного видео на YouTube. Казалось бы, задача на пять минут. Заняла полтора часа. Делюсь опытом — может кому пригодится последовательность решений. . . .	21 мат мед. Планы на развитие модели здравоСохранения anaschu 01.06.2026 AnyLogic: план развития симуляционной модели рабочего коллектива — динамический абсентеизм, реальные данные, три сценария сравнения Продолжаю серию постов о дискретно-событийной модели рабочего. . .	20. Мат мед. Абсентеизм как отдельный тип простоя anaschu 29.05.2026 Апдейт модели: исправленные баги, абсентеизм и новые механизмы Продолжаю развивать ранее описанную модель рабочего коллектива на AnyLogic. За последние несколько дней был проведён серьёзный. . .
19. здоровье, усталость и психотип работника влияют на производительность предприятия, и наоборот, производительность на здоровье, усталось и психотип anaschu 28.05.2026 Дискретно-событийная модель рабочего коллектива на AnyLogic: здоровье, выгорание, психотипы и микростимуляция Привет, коллеги. Хочу поделиться итогами нескольких недель работы над симуляционной. . .	"Прокси" для последовательного порта Eddy_Em 28.05.2026 Эту штуку написал я достаточно давно. Но сейчас вот понадобилось настроить датчик грозы, но при этом не отключать его от "метеодемона". Соответственно, надо запустить этот "прокси": метеодемон будет. . .	Рефакторинг программы уравнивания. Massaraksh7 26.05.2026 Пример по предыдущей записи в блоге. Но, надо заметить, что, во-первых, там оптимизация не только математики, но и работы с базой данных, и с графами, а во-вторых, это ещё не всё.	Использование TThread в Lazarus для математических вычислений. Massaraksh7 25.05.2026 Производя рефакторинг своих программ на предмет ускорения их работы, обратил внимание на такой аспект, как сокращение времени матвычислений. Дело в том, что приходится работать с большими матрицами. . .

@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