OberonCore

Почему-то при выполнении выдаёт FALSE.
у меня BB 1.7.1

Пока не вник детально, но сразу скажу, что сравнивать действительные числа нельзя. Их можно только вычитать и смотреть отличается ли разница на некоторый eps (очень малую величину).

StdLog.Bool(ABS((0.12 * Math.IntPower (10, 2)) - (0.12 * Math.IntPower (10, 2))) < 10.0E-10); StdLog.Ln;

Заметил, что ABS в объявлении о языке не определён для REAL, но тем не менее работает...

А почему? Загнал одно число в один регистр, другое - в другой и сравнил их побитово.

Но это же тоже сравнение.

Как мне кажется, раз и левая и правая части равенства выполняются по одному и тому-же алгоритму, то где-то в Math к числу "примешивается что-то из вне". Может где-то там не выставляется исходное значение переменной перед её использованием.

У меня ещё вот какой вопрос: сколько бит отводится под мантиссу и сколько под экспоненту в типе REAL?

IEEE 754 64 бит (см. например, https://ru.wikipedia.org/wiki/IEEE_754-2008 )

Сравнение, но уже правильное

тем не менее, это баг. потому что результат обоих выражений должен быть bit-to-bit exact. и, как полагается, в двух нижепроцитированых случаях получаем ожидаемое "$TRUE":

вообще, мне сейчас вникать не особо есть возможность, но есть мнение, что виноват вот этот код:

мы здесь видим что? а видим мы сравнение 80-bit real (внутреннего формата FPU) — и округлённого до 64 бит результата предыдущего выражения. в тех же случаях, которые я процитировал, оба результата округляются (потому что сохраняются в память) — и бага нет.

как вариант — насильно перевести FPU в режим 64-битных вычислений, например. или просто смириться, запомнить, что результат вычислений с плавающей точкой имеет нестабильный ULP, и писать код с учётом этого.

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

проблема, однако же, в том, что всякие разные внешние библиотеки, например, тоже любят FPU трогать лапами немытыми. приснопамятный DirectX, например, вообще любил перевести его в одинарную точность и так оставить. а что, хватит всем. другие же библиотеки могут ожидать конкретных режимов, установленых их любимым компилятором си — или тупо форсить его обратно.

это и сейчас проблема, на самом деле. если я верню помню, именно поэтому стандартный CP2 заново инициализирует FPU после каждого обращения к внешней библиотеке (что я в LC отрезал). тормоза-с адовые.

короче, красивого и правильного решения у проблемы FPU нет. можно, конечно, сменить слово инициализации (кажется, где-то в Kernel; и не забыть проверить CP2 — там, по-моему, тоже забито волшебное число) — и это проблему спрячет.

более лучший вариант решения — перестать использовать FPU, и обучить кодоген использовать SSE.

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

и в любом случае утешиться тем, что FPU — это была общая боль, не специфичная для оберона. компиляторы си тоже насильно скидывали результат в память, чтобы округлить, например.

ещё хороший вариант — последовать заветам Чака Мура: забить на floating point и использовать fixed point. но ни в коем случае не с LONGINT, потому что для лонгинтов CP2 использует FPU. floating point is overrated.

а вот этому никакие игры с FPU не помогут. IEEE требует стабильный результат, не более. разница в ULP на разных железных/программных реализациях допустима, например, если она стабильна. так что вычисления с floating point в принципе непортабельны между разным железом (и даже не обязаны быть переносимы между разными ревизиями одного и того же). я уж не говорю про вычисления квадратных корней, всяких там трансцендентальных функций и других страшных гитик. или вот кто-то (да, я смотрю на тебя, SSE!) может криво реализовать субнормалы, например.

в общем, в mission-critical вычислениях надо или жёстко привязаться к строго определённому железу, или не использовать floating point вообще. поэтому проблема переносимости подобных вычислений значения не имеет, я считаю.

Да, поэтому и говорю, что "запомнить, что результат вычислений с плавающей точкой имеет нестабильный ULP, и писать код с учётом этого" — это вот стратегически правильно, а остальное "от лукавого" ))


вот такой код переносим

а в каком коммите это реализовано? это была бы классная опция компилятора, изучить было бы любопытно на каком-то примере

не помню, но никакой ракетной науки, право слово.

в DevCPC486, процедура "Enter". там в конце написано: "IF useFpu THEN InitFpu END". что, в общем, верное и надёжное решение, но я его посчитал совершенно излишним, и просто это закомментарил.

и заодно наврал: реинит делается вообще при каждом входе в процедуру, которая использует FPU. омики серьёзно к этим делам относилиь, да.

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

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

опять же: вычитание из большого флоата какого-нибудь субнормала даст в итоге тот же самый большой флоат, как ни уменьшай эпсилон.

флоаты — это СЛОЖНА! ;-) если можно обойтись без них — лучше обойтись. вон, в ящике предпочли для устройство-независимых координат fixed point, хотя могли бы и floating.