Навеяло постоянным упоминанием автомата Калашникова в нашей ветке.
На RSDN вспомнили старый анекдот:
Оптимист изучает английский язык.
Пессимист -- китайский.
Реалист -- автомат Калашникова.

Ответ на »сообщение 2414« (Сергей Губанов)
___________________________

Ответ на »сообщение 2413« (AVC)

Вопрос ко всем участникам.
Как вы думаете, имеет ли смысл разбить данную ветку на несколько более конкретных?

По конкретным вопросам лучше каждый раз создавать новую тему в http://bbforum.metasystems.ru/
Здесь же, так сказать, изливается поток общественного сознания... :-)

В частности, обсуждение проблем численных методов я уже предлагал перенести туда. :)

P. S. Да не сочтет Королева сие призывом к эмиграции жителей. :D Это только предложение выехать в зарубежную командировку. :):):):)

Ответ на »сообщение 2413« (AVC)

Вопрос ко всем участникам.
Как вы думаете, имеет ли смысл разбить данную ветку на несколько более конкретных?

По конкретным вопросам лучше каждый раз создавать новую тему в http://bbforum.metasystems.ru/
Здесь же, так сказать, изливается поток общественного сознания... :-)

Вопрос ко всем участникам.
Как вы думаете, имеет ли смысл разбить данную ветку на несколько более конкретных?
Если да, то на какие именно?

Ответ на »сообщение 2411« (Денис Зайцев)
___________________________

К сожалению, не могу привести ссылку на статью, но приведу пример из неё: вычисление сопротивления двух резисторов, соединённых параллельно. Сопротивление первого - R1, второго - R2. Формула, известная из школьного курса физики, такова: R = R1*R2/(R1+R2). Но её же можно записать в другом, математически эквивалентном виде: R = 1/(1/R1 + 1/R2). Несмотря на математическую эквивалентность этих двух выражений, интервальные оценки для R будут разными. Хотите - верьте, хотите - проверьте (ключ к пониманию - в первом выражении R1 и R2 участвуют по 2 раза, а во втором - по разу). Т.е. выбор наиболее "хорошего" выражения всё равно ложится на программиста.


Такой пример есть в SICP:
http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-14.html#%_sec_2.1.4

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

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

1) Подход, основанный на интервальной арифметике, не является панацеей. У него тоже есть проблемы. К сожалению, не могу привести ссылку на статью, но приведу пример из неё: вычисление сопротивления двух резисторов, соединённых параллельно. Сопротивление первого - R1, второго - R2. Формула, известная из школьного курса физики, такова: R = R1*R2/(R1+R2). Но её же можно записать в другом, математически эквивалентном виде: R = 1/(1/R1 + 1/R2). Несмотря на математическую эквивалентность этих двух выражений, интервальные оценки для R будут разными. Хотите - верьте, хотите - проверьте (ключ к пониманию - в первом выражении R1 и R2 участвуют по 2 раза, а во втором - по разу). Т.е. выбор наиболее "хорошего" выражения всё равно ложится на программиста.

2) Представление рациональных чисел в виде отношения целых. Очевидное ограничение этого подхода - он допустИм только для операций, не выводящих за пределы множества рациональных чисел. Первое попавшееся, скажем, извлечение корня его рушит. Кстати, по этому пути пошёл так горячо всеми нами любимый Лисп. Там есть 3 числовых типа - целые числа (произвольно большой разрядности), рациональные (отношения целых) и всё-таки (увы!) числа с плавающей точкой. Пока возможно, Лисп пытается все вычисления производить в целых числах, если не получается - переходит к рациональным, ну а если и это не спасает - к плавающей точке.
Следует также добавить, что даже для "рациональных" операций числитель и знаменатель часто имеют тенденцию к сильному росту, что неприемлемо замедляет быстродействие.

3) Ну и, наконец, символьная алгебра. Первые 2 подхода можно рассматривать как частные случаи этого. Думаю, тут и комментировать нечего. Он чрезвычайно медленный (по сравнению с плавающей точкой), очень сложен в реализации (не желаете ли реализовать функциональность MAPLE, MATHCAD, MATHEMATICA и т.п. в Вашем языке программирования???) и опять же годится не для всех случаев.

Ответ на »сообщение 2387« (Антон Григорьев)
___________________________


с границами integer'ов всё просто - мы их можем просто полстулировать, не заостряя внимания на том, что именно такие значения определяются аппаратной реализацией

Достаточно ли? Например, двоичное представление "two's complement" имеет известные дефекты, вроде -(2^{n-1}) = 2^{n-1}, где n --- основание системы счисления, или (-1) >> 1 = -1 или то, что остаток от деления отрицательных чисел тоже отрицателен (что противоречит математическому определению этой операции, не так ли?). Соответственно, чтобы формально доказывать свойства программ, придется учитывать и эти особенности.

Кроме того, есть еще и такая презренная реальность, как арифметическое переполнение. Некоторые архитектуры при его обнаружении генерируют прерывания, некоторые --- нет. Соответственно, и подходы к обработке переполнений в программах получаются архитектурно-зависимыми, не так ли? (Универсальный подход "проверять аргументы перед каждой операцией", скажем так, не всегда эффективнее по времени выполнения, чем возможность перехватить соотв. прерывание.) В языке Си, насколько мне известно, ответственность за подобные ситуации возлагается исключительно на программиста, но он ИМХО и не претендует на звание машинно-независимого языка. С другой стороны, в стандарте Common Lisp зафиксирована "прозрачность" перехода к целочисленной арифметике повышенной точности, если таковая потребуется (хотя, и это, насколько мне известно, для эффективности можно выключить соотв. директивами компилятора).

Ответ на »сообщение 2400« (Антон Григорьев)
___________________________

Я вообще не понимаю, что это самое машинное эпсилон даёт. По определению это - минимальное число, для которого выполняется неравенство 1.0+Eps>1.0. При попытке прибавить к единице число, меньшее чем машинное эпсилон, мы должны получить единицу из-за ошибки округления. Но это - оценка погрешности одной только операции, и ожидать, что она окажется универсальной, оснований я не вижу.

Вот здесь

http://en.wikipedia.org/wiki/Fortran_language_features#Number_model_and_intrinsic_functions

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

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

Интересная статья "The Perils of Floating Point":
http://www.lahey.com/float.htm

Объясняет многие возникшие вопросы.

Ответ на »сообщение 2396« (AVC)
___________________________
>>>Вопрос, как выбрать значение EPS?
>>>(Следует учесть, что sqrt -- библиотечная функция.)


- Будьте добры, скажите, пожалуйста, как мне отсюда выбраться?
- Многое зависит от того, куда тебе нужно добраться, - сказал Кот.
- Мне в общем-то все равно куда… - начала было Алиса.
- В таком случае, - прервал ее Кот, - все равно какой дорогой идти.
- Но куда-нибудь я все-таки хотела бы добраться, - пояснила Алиса.
- Об этом не беспокойся, - ответил Кот, - иди как можно дольше и в конце концов куда-нибудь да попадешь.