Здравствуйте, __kot2, Вы писали:

__>Здравствуйте, netch80, Вы писали:
N>>В этом смысле решение, чему равно 1/0 — вообще не существует, ∞ без знака, +∞ или ещё чему-то — просто выбор контекста для работы, и контекст, где это противоположное нулю значение на числовой окружности, не менее важен, чем тот, где значения не существует. Он просто другой.
__>если вы когда-нибудь брали какой-нибудь большой интеграл или пытаись доказать хитрую теорему, то вы знаете, что маааленькая ошибочка где-то посредине рассуждений аннулирует все рассуждения.

Да. Но при чём тут это? Если посреди вычислений возникнет Inf (которое в IEEE754 означает не бесконечность вообще, а "значение, не поместившееся в стандартные размеры, или его потомок в операциях"), то, если это Inf не будет скомпенсировано тем, что где-то оно вообще неважно, так и останется Inf, то есть признаком "когда-то было переполнение". Аналогично для NaN. У вас не возникнет неожиданно корректно выглядящего, но неправильного значения, только за счёт того, что где-то раньше были Inf или NaN.

__>вы не можете дополнить вещественные числа двумя бесконечностями, так как, например, дополнение 1/x в нуле противоречит определению ф-ии.

Мнэээ... подробнее, пожалуйста. Функция, насколько я помню, это отображение, которое для каждого прообраза из области определения даёт один и только один образ из области значений. Так?
И каким же образом это дополнение противоречит определению функции, если для f(x)=1/x
1) мы добавляем значения 0 и ∞ в обе области (определения и значения);
2) функция переводит их друг в друга;
3) значение функции для любого другого значения из ℝ этим не меняется
?

__>вы не можете дополнить вещественные числа одной бесконечностью и сохранить их упорядоченность,

А кто говорил про такую же линейную упорядочённость, и что она в этом случае должна сохраняться? Естественно, я не требую её сохранения (в том же виде) в случае включения ∞.

__> то есть не можете пользоваться другими свойствами вещ. чисел, так как inf < x < inf.

Могу. С соответствующими уточнениями. Вас же не приводит в ступор, например, то, что для комплексных чисел уже нельзя определить стандартные сравнения типа "меньше"? Или что квадратный корень ℝ->ℝ почему-то в друг при выходе в ℝ⁻ перестаёт работать? Почему там могут возникать уточнения, а тут — нет?

__>все ваши рассуждения, которые вы построите на базе этих чисел, будут неправильными с самого начала, соверенно не важно, какими красивыми они будут

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

__>у меня есть подозрения, что, по-аналогии, возможность проводить операции с nan тоже фундаментально абсурдны, как и факт иметь обьект в невалидном состоянии вообще.

Это просто другой подход. Можно признак невалидности держать отдельно, а можно — встроенно. Второй подход очень распространён из-за его банального удобства. Например, указатель, равный NULL (nullptr, nil и т.д.) В большинстве реализаций внутри NULL — число 0. Это значит, что вы не можете для каких-то сурово системных целей читать/писать память по адресу 0; но вы в таком случае не можете использовать логику, что NULL означает признак невалидности указателя. Или open(), которая выдаёт в int дескриптор файла (если >=0) или признак ошибки (-1), а не отдельный флаг ошибки. Дотнетовский Nullable<T> в этом смысле — удобная контейнеризация отдельного признака невалидности, пригодная ко всему, но удорожанием. В IEEE754 сделали встроенный.

__> мы не можем иметь int имеющий одновременно и плюс и минус. мы не можем иметь букву, которая одновременно и а и б. мы не можем иметь строку ненулевой длины начинающейся с 0.

C-строка, начинающаяся с NUL? Прошу быть корректнее в терминах. А то всяким std::string это никто не запрещает.

__> мы не можем иметь bool, который одновременно true и false. то есть мы все это можем сделать, но все это будут обьекты в невалидном состоянии. и вместо того, чтобы писать код для каждого из таких случаев, нам было бы в сто раз удобнее не допускать такое состояние вообще.

Не вижу никаких причин утверждать про "удобнее", тем более "в сто раз", и вижу противоположные тенденции, как на своём опыте, так и на опыте всей отрасли (выражающемся в создании значений типа NULL и NaN, возврате -1 по ошибке, и т.п.).
И пример с bool некорректен, если вспомнить fuzzy logic (нечёткую логику) и её признаки вероятности какого-то значения.
И "этот int положительный с вероятностью 69% и отрицательный с 26%" тоже возможно, если этого требует модель.

__> возникновение такого состояния — abort()

Повторюсь: включите через feenableexcept() все разрешения исключений и наслаждайтесь abort() по минимальной проблеме. Но текущий стандарт писали люди, у которых было явно больше опыта.