Плавающая запятая. Помогите разобраться.

[Mathdream]

Пусть мы работаем с 6-значной арифметикой. Если в ходе решения получаем число 0.27 и нам нужно его использовать дальше, то мы рассматриваем его как 0.270000 или мы безвозвратно потеряли остальные 4 цифры и работаем в 2-значной арифметике?

[gris]

Если в 6-значной получили 0.27, то это означает $0.270000\pm e; |e|\le 0.0000005$
то есть мы теряем только седьмую цифру(ну и следующие)

[Mathdream]

То есть, если мы из 1111.38 вычитаем 1111.11, то результатом считаем 0.270000
Но это же нечестно! Мы ведь не знаем, что там дальше на самом деле!!!

[gris]

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

[Mathdream]

Верно, но меня интересует скорее теоретическая сторона вопроса, нежели практическая.
Важно - переходим ли мы к двухзначной арифметике!! Просто, если нам затем надо прибавить, к примеру, 0.127456, то мы округляем 0.127456 до 0.13 и считаем 0.27+0.13=0.40 или 0.270000+0.127456=0,397456? Если первое, то это расточительно, но корректно, если второе - то, видимо некорректно, да???

[gris]

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

[Pavia]

Mathdream
Возьми и почитай как устроенны числа с плавующей точкой.
0.270000+0.127456=0,397456 - это корректно

[AD]

gris в сообщении #184950 писал(а):

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

Давайте поясню, что-ли. Есть такая классическая задачка по программированию - вычислить сумму $\sum\limits_{n=1}^{10000000}\frac1{n^2}$ и сравнить с точным значением суммы до бесконечности (это $\frac{\pi^2}6$). Ну все начинают суммировать:

float n, s=0;
for (n=1; n<=10000000; ++n)
    s+=1./(n*n);

и получается ужасно неправильно. Потом им объясняют, что складывать надо в обратном порядке:

float n, s=0;
for (n=10000000; n>=1; --n)
    s+=1./(n*n);

, и тут же всё получается правильно. Проблема - именно та, которую мы тут обсуждаем. У меня на этих примерах разница в 4-м знаке набегает: 1.644725 vs 1.644934

[mkot]

Mathdream писал(а):

То есть, если мы из 1111.39 вычитаем 1111.11, то результатом считаем 0.270000
Но это же нечестно! Мы ведь не знаем, что там дальше на самом деле!!!

Как известно, погрешности при сложении складываются:
$(x + \Delta x) + (y + \Delta y) = (x + y) + (\Delta x + \Delta y)$,
при вычитании тоже складываются:
$(x + \Delta x) - (y + \Delta y) = (x - y) + (\Delta x + \Delta y)$,
Поэтому, так как мы вычитаем из $1111.39 \pm 0{.}01$ число $1111{.}11 \pm 0{.}01$, то получаем:
$1111{.}39 \pm 0.01 - 1111{.}11 \pm 0{.}01 = 0.27 \pm 0{.}02$.

Далее, мы складываем $0.127456 \pm 0{.}000001$ и $0{.}27 \pm 0{.}02$:
$0.127456 \pm 0{.}000001 + 0{.}27 \pm 0{.}02 = 0{.}397426 \pm 0.020001$.

[ИСН]

Mathdream в сообщении #184937 писал(а):

Но это же нечестно!

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

[ewert]

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