SIGFPE Arccos на sqrt, в процедуре из 2-х строк, что делать?

[max]

Таким образом начать нужно с того, что перед её применением проверяем аргумент на вхождение в диапазон допустимых значений:

Не. Значения там передаются и передавались верные. Но если значение после запятой длинное типа 0.99999999999999999999999999999999999999999999999999. То в функции arccos где-то перед sqrt -- число как-то волшебно становилось отрицательным. И это приводило к SIGFPE на sqrt. Если же модифицировать arccos и добавить там abs перед sqrt, то SIGFPE -- уже не возникало. И + у меня там Extended, а не Double. Может быть есть какое-то решение запрещающее/адаптирующее -- числа с переполнением после запятой, для всей программы ?!

[Vadim]

{$OVERFLOWCHECK ON} - Проверка переполнения
{$RANGECHECK ON} - Проверка диапазона
?

Значения там передаются и передавались верные. Но если значение после запятой длинное типа 0.99999999999999999999999999999999999999999999999999.

То они будут неверные...
По умолчанию в конфигурационном файле FPC, для ускорения работы программы, ключики проверки переполнения, диапазона и ввода\вывода отключены...

[max]

$OVERFLOWCHECK

This means that the compiler inserts code to check for overflow when doing computations with integers. <= а нужно float. ( https://www.freepascal.org/docs-html/prog/progsu64.html )

Вставил в начало юнита, ответ был незамедлительным:

Warning: Illegal compiler directive "$OVERFLOWCHECK"
Warning: Illegal compiler directive "$RANGECHECK"


заменил на:

{$Q+} //- Проверка переполнения
{$R+} //- Проверка диапазона


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

[Vadim]

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

[max]

С названиями я мог и ошибиться

наоборот хорошо, т.к. -- это помогло мне быстро найти описание этих директив.
https://www.freepascal.org/docs-html/prog/progsu65.html
https://www.freepascal.org/docs-html/prog/progsu64.html

Буду надеяться, что теперь там всё проверяется. Спасибо.

[Vadim]

max
И всё-таки попробуйте вставить тот код проверки, что я Вам написал. После ввода, вне зависимости от того, что Вы ввели, в переменной уже будет то число, с которым будет работать функция. И именно значение переменной надо проверить на допустимость.

[max]

код проверки

Уже проверял -- программа всегда вычисляет одни и те-же углы, соответственно ошибка 100% была не в этом, т.к. сообщение "Лапуль я в шоке, от таких экзерсисов с числами больше 1 или меньше -1" -- не возникало и не возникает.

[Alex2013]

Вообще все это похоже на банальный глюк памяти . Суть проблемы в том что практически любое современное ОЗУ (по сути это "зомби" существующий за счет перманентной "реанимации"(регенерации) ) по умолчанию не идеально (да еще есть срывы кеша и сбои предсказания ветвлений в CPU, да теоретически это должно сказываться только на быстродействии но видимо "возможны варианты" )...
Так что в случае действительно важных вычислений как вариант стоит запускать контрольные расчеты в гарантированно разных потоках и желательно разными методами ведь обычно подобный "плавающий" сбой ошибки не вызывает, но в расчет вкрадываются разной степени критичности ошибки .
Зы
Кстати что с оптимизацией ? Уровень Q4 иногда впечатляет реально впечатляющими глюками ....

[Снег Север]

Alex2013, я встречал и не такие глюки... Например, стандартное преобразование строки в целое, если в строке значение, больше максимально допустимого целого - компилятор win32 правильно генерирует ошибку, а компилятор win64 выдает херню, но ошибку не генерирует.

[max]

что с оптимизацией ?

на дебаге -- дружественно к отладчику.
на релизе -- 3
И там и там падало с SIGFPE. вчера вечером и сегодня утром. А потом, чёртов баг сбежал (((((((.

глюки

у меня появилось предположение, что парсер, при определённой последовательности функций / литералов / переменных -- мог отправлять не в те регистры. И это как-то приводило к изменению знака, в arccos. Но теперь -- это уже невозможно проверить, т.к. баг сбежал ((((((

[Vadim]

...а компилятор win64 выдает херню, но ошибку не генерирует.

К компилятору Win64 пока что стоит относиться с очень большой опаской...

Добавлено спустя 8 минут 33 секунды:
Re: SIGFPE Arccos на sqrt, в процедуре из 2-х строк, что делать?
max
Я бы Вам посоветовал пользоваться только типом Double. На сегодняшний день он единственный, кто для плавающей точки даёт наименее глючные результаты. Этот тип даже можно отнести к точным. Понятно, имея в виду, что у плавающей точки точных результатов пока что быть не может. Вот если бы в 16 веке победила точка зрения, что дроби надо решать не с помощью десятичной, а с помощью шестидесятиричной системы, тогда можно было бы говорить о точных вычислениях.
Extended, увы, даже при простом присваивании способен самоокруглиться до такой степени, что будешь долго пялиться на получившийся результат размышляя, то ли напиться и кого-нибудь зарезать, то ли застрелиться...
Если нужно непременно работать с длинными числами, тогда лучше взять специальный модуль для этого, там хоть округление можно определить самостоятельно, что позволит минимизировать ошибку.

[max]

Extended, увы, даже при простом присваивании способен самоокруглиться до такой степени,

В arccos все вычисления именно Extended, так что, чтобы я ни брал, в arccos оно будет преобразовано к Extended. И наоборот лучше брать Extended, т.к. при подобных вычислениях, есть ещё куча подводных камней. Обсуждение есть где-то тут на форуме и там много примеров, о том как из-за плавающей точки (точнее из-за неправильной архитектуры процессоров) -- возникают легко-воспроизводимые ошибки в вычислениях.