OberonCore

Предлагаю к обсуждению такой код:

Этот код даёт такой результат:

Возникает два вопроса:
1. Почему первый результат отрицательный?
2. Почему первый и второй результаты различны?

Собственно, прямые ответы на эти вопросы нам известны и потому не интересны.
Но должно ли так быть? Разве ЯВУ не должен нас изолировать от внутренних форматов хранения вещественных чисел (IEEE Standart 754, если не ошибаюсь)?

Замечу, что проблема касается всех ЯВУ. КП здесь использован только для примера.

Замечу также, что проблема не "высосана из пальца". Мне в таких случаях приходилось использовать доверительные интервалы, и вместо точного сравнения проверять попадание в этот интервал. Но постоянное использование этого приёма утомляет. Хотелось бы решить проблему на уровне языка.

Ха ха ха.

Подозреваю, что вернее всего идти по пути интервальной арифметики.

http://www.php.net/manual/ru/language.types.float.php


Так что на уровне языка это неразрешимый вопрос, ну нельзя представить 0.1 в двоичной форме без потери точности. А вот простенькую функцию для сравнения легко написать. Вообще, достаточно редко требуется сравнивать числа с плавающей точкой. Интересно было бы узнать вашу задачу.

Проблема решается просто: в языке должно быть запрещено сравнение вещественных чисел на равенство.

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

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

Звучит как "вертикальный полёт не возможен"

Так ведь никто и не ставит такой цели

Не, не интересно. Если возникают такие проблемы, то я их успешно решаю. А хотелось бы вообще избежать возникновения таких проблем. То есть хотелось бы перенести решение с уровня моей задачи на уровень языка.

Ну, да. Чтобы не было больных и несчастных, нужно расстрелять всех больных и несчастных. И тогда все будут здоровы и счастливы.

А неплохое решение.

Поправка: вещественных разного размера. Проблема ведь в этом.

1. Если говорить об обучении, то ни о каких размерах начинающему знать ни к чему.
2. Можно запретить сравнение вещественных разного размера.
3. Можно запретить присваивание вещественных разного размера в обе стороны. Я так понимаю, что либо нам нужна точность, либо мы экономим память. Зачем нам два размера в одной программе?
4. Если сравнения на равенство чисел разного размера разрешены, тогда должно быть преобразование типа, в точности приводящее большую мантиссу в соответствующему значению малого размера. Проблема же в хвостике - паре последних разрядов.

Думаю, что запрет должен касаться вещественных одинакового размера тоже, поскольку значение (и равенство!) может зависеть от способа вычисления, то есть от алгоритма.

Да.

Тогда уж лучше было бы исключить все вещественные типы, кроме одного - самого точного. Но проблема, вроде, не только в этом.

Интересная мысль.

PS: Вообще я не сторонник решения проблем запретами, но признаю что частенько таких решений не избежать

А что вы можете предложить взамен?

Ну как. Следить за ошибками и неравенства.
Floating-point на кривой кобыле не объехать.

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

А если число1 и не больше и не меньше числа2 , то что тогда? Равно?

То есть вместо сравнения на равенство использовать сравнение на больше или меньше? Ну, это вроде ничего не меняет. Результату такого сравнения мы по прежнему не можем доверять.

Где б её взять только, прямую кобылу.

Суть проблемы, вроде как, состоит в том, что три дискретных числовых оси не совпадают. Эти дискретные числовые оси соответствуют десятичному представлению и двум двоичным (SHORTREAL и REAL).

Парочка замечаний:
1. Так как мы не можем в исходном тексте записать число из бесконечного числа цифр, то мы никогда не имеем дело с непрерывной числовой осью.
2. Результаты вычислений всегда отоборажаются на дискретную числовую ось, соответствующую двоичному представлению. А непосредственные вещественные константы - на дискретную ось, соответсвующую десятичному представлению.

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

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

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

Если предположить, что поставленная задача будет решена, то при сравнении вещественных чисел необходимо будет проверять отображаются эти числа в один и тот же интервал или в разные.

То, что я изложил - не решение, а скорее постановка задачи. Боюсь, что эта задача вообще не имеет эффективного решения.