Точность компьютерных вычислений

[Alex9]

Как посчитать точность (количество знаков после запятой), которую могут обеспечить вычисления на моем компьютере ? Программа очень много знаков может выдать, но все ли из них будут верны ?

[Алексей К.]

Стандартными методами оценки погрешности суммы, произведения, других функций, в зависимости от точности операндов.
Ну а точность вычисления, например, $x^2-y^2$ будет зависеть от того, вычисляете ли Вы это как написано, или позаботились о точности и прописали это в программе как $(x-y)(x+y)$.

[Deggial]

Тема перемещена из форума «Математика (общие вопросы)» в форум «Помогите решить / разобраться (М)»
Перенёс в более подходящий раздел

[ewert]

Никак. Смотря какие вычисления.

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

[Алексей К.]

ewert в сообщении #714908 писал(а):

внутренние регистры имеют некоторый запас дополнительных разрядов, в которых погрешности округления и гасятся

Операнд имеет погрешность ещё до попадания во внутренний регистр.

[ewert]

Алексей К. в сообщении #714982 писал(а):

Операнд имеет погрешность ещё до попадания во внутренний регистр.

Естественно. Однако при вычислении какого-нибудь там синуса она не возрастает -- как было бы, если бы резерв отсутствовал.

[iifat]

Компьютер -- дурень, программист -- молодец! Не путайте точность вычислений на компьютере с возможностями процессора. "Вычисления с многократной точностью" -- слышали такой термин?

[ewert]

iifat в сообщении #714988 писал(а):

"Вычисления с многократной точностью" -- слышали такой термин?

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

[iifat]

Знамо, тормозит. Только напоминаю: вопрос был о точности. Программёж -- во многом поиск компромисса. Нужна скорость -- считай приблизительно. Нужна точность -- терпи долгое время.

[Alex_J]

Вопрос актуальный. Как я писал в теме "x-1/x", вычисление рекуррентных последовательностей, особенно таких как $x_{n+1}=x_n-\frac{1}{x_n}$, очень чувствительно к погрешностям. И влияние на характерные особенности поведения последовательности начинает оказываться довольно быстро.

Как производится, например, сложение $1.2345678901234567890123\cdot10^{10}+1.2345678901234567890123\cdot10^{-10}$ ? При таком кол-ве значащих разрядов должно произойти, видимо вот что: второе слагаемое округляется до $1.23\cdot10^{-10}$ и результат получается $1.2345678901234567890246\cdot10^{10}$. Значит, $\delta x$ второго слагаемого не $10^{-23}$, а аж $10^{-2}$, и всё, вычисления испорчены. За 100 итераций погрешность достигает 100%.

И это не считая странной фишки форматов семейства float, когда несколько младших разрядов (1-3) отличаются изначально от заданного значения. Например, если написать float a=4.0 , то проверка может показать, что a равно чему то типа 4.000000000035 . И как с этим работать?

Deggial: синтаксис оформил тегом tt.

[iifat]

Не совсем понял вопрос. Если вам интересна работа процессора, то он сдвигает мантиссу числа с меньшим порядком вправо, выравнивая порядки. Значащих цифр (у x86), помнится, 12 шестнадцатиричных для восьмибайтного целого, так что кое-что может и потеряться.
Если вам нужно конкретное вычисление с большой точностью -- можно вычислять в рациональных числах многократной точности. Разумеется, это будет медленнее.

[ewert]

Alex_J в сообщении #714997 писал(а):

если написать float a=4.0 , то проверка может показать, что a равно чему то типа 4.000000000035

Не верю. Вот если бы float a=0.4, то тогда, конечно, возможно.

[TOTAL]

Alex_J в сообщении #714997 писал(а):

Например, если написать float a=4.0 , то проверка может показать, что a равно чему то типа 4.000000000035 . И как с этим работать?

Если в пятизначном числе проверить седьмую цифру, то проверка может показать что попало.

[Joker_vD]

ewert
При вычислении трансцендентных функций — возрастает.

-- Ср апр 24, 2013 20:36:30 --

W. Kahan в "A Logarithm Too Clever by Half" писал(а):

No general way exists to predict how many extra digits will have to be carried to compute a transcendental expression and round it correctly to some preassigned number of digits. Even the fact (if true) that a finite number of extra digits will ultimately suffice may be a deep theorem.

http://www.cs.berkeley.edu/~wkahan/LOG10HAF.TXT

[Xaositect]

Alex_J в сообщении #714997 писал(а):

Вопрос актуальный. Как я писал в теме "x-1/x", вычисление рекуррентных последовательностей, особенно таких как $x_{n+1}=x_n-\frac{1}{x_n}$, очень чувствительно к погрешностям. И влияние на характерные особенности поведения последовательности начинает оказываться довольно быстро.

Как производится, например, сложение $1.2345678901234567890123\cdot10^{10}+1.2345678901234567890123\cdot10^{-10}$ ? При таком кол-ве значащих разрядов должно произойти, видимо вот что: второе слагаемое округляется до $1.23\cdot10^{-10}$ и результат получается $1.2345678901234567890246\cdot10^{10}$. Значит, $\delta x$ второго слагаемого не $10^{-23}$, а аж $10^{-2}$, и всё, вычисления испорчены. За 100 итераций погрешность достигает 100%.

И это не считая странной фишки форматов семейства float, когда несколько младших разрядов (1-3) отличаются изначально от заданного значения. Например, если написать float a=4.0 , то проверка может показать, что a равно чему то типа 4.000000000035 . И как с этим работать?

Во первых, надо понимать, что такое float и double, с чем их едят, и почему последние цифры не хотят обнуляться. В идеале прочитать http://docs.oracle.com/cd/E19957-01/806 ... dberg.html .После этого Вы уже сможете понять, хватит ли Вам возможностей процессорной floating-point арифметики.
Во-вторых, есть библиотеки для вычислений с высокой точностью, напр. MPFR.
В-третьих, такие штуки можно считать в виде точных рациональных чисел $\frac{p_{n+1}}{q_{n+1}} = \frac{p^2_n - q^2_n}{p_nq_n}$. Только знаменатели часто растут экспоненциально, поэтому все равно потребуется либо библиотека целых чисел типа GMP или MPIR или язык программирования, в котором встроен тип длинных чисел с помощью такой библиотеки, напр. Haskell, Python или что-нибудь специализированное математическое.