Неожиданная потеря точности при делении двойников

Я пробовал с float вместо double и в результате получил 10,845110. Это все еще выглядит лучше, чем результат Мадалины.

РЕДАКТИРОВАТЬ:

Думаю, я знаю, почему вы получаете такие результаты. Если вы получаете параметры a, b, c и d откуда-то еще и распечатываете их, это дает вам округленные значения. Тогда, если вы поместите его в Mathemtacia (или calc;)), это даст вам другой результат.

Я попытался немного изменить один из ваших параметров. Когда я сделал:

double c = 2.7041304;

Я получаю 10.845806. Я добавляю только 0,0000004 к c! Так что я думаю, что ваши "ошибки" не являются ошибками. Выведите a, b, c и d с большей точностью, а затем поместите их в Mathematica.

Следующий код:

#include <iostream>
using namespace std;

double getSlope(double a, double b, double c, double d){
    double slope;
    slope=(d-b)/(c-a);
    return slope;
}

int main( ) {
    double s = getSlope(2.71156, -1.64161, 2.70413, -1.72219);
    cout << s << endl;
}

дает результат 10,8452 с g++. Как вы печатаете результат в своем коде?

Может быть, вы используете DirectX или OpenGL в своем проекте? Если это так, они могут отключить двойную точность, и вы получите странные результаты.

Вы можете проверить настройки точности с помощью

std::sqrt(x) * std::sqrt(x)

Результат должен быть довольно близок к х. Я столкнулся с этой проблемой давно и провожу месяц, проверяя все формулы. Но потом я нашел

D3DCREATE_FPU_PRESERVE

Проблема здесь в том, что (c-a) мало, поэтому ошибки округления, присущие операциям с плавающей запятой, в этом примере увеличиваются. Общее решение состоит в том, чтобы переработать ваше уравнение, чтобы вы не делили его на небольшое число, хотя я не уверен, как вы это сделаете здесь.

РЕДАКТИРОВАТЬ:

Нил прав в своем комментарии к этому вопросу, я вычислил ответ в VB, используя Doubles, и получил тот же ответ, что и mathematica.

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

Предполагая, что показанный код является тем, что выполняется, т. е. вы ничего не конвертируете в строки или числа с плавающей запятой, тогда в C++ нет исправления. Это выходит за рамки кода, который вы показали, и зависит от среды.

Поскольку Патрик Макдональд и Треб подняли и точность ваших входных данных, и ошибку на a-c, я решил взглянуть на это. Одним из методов рассмотрения ошибок округления является интервальная арифметика, которая делает верхнюю и нижнюю границы, которые представляет значение, явными (они неявны в числах с плавающей запятой и фиксируются в соответствии с точностью представления). Рассматривая каждое значение как верхнюю и нижнюю границу и расширяя границы на ошибку в представлении (приблизительно x * 2 ^ -53 для двойного значения x), вы получаете результат, который дает нижнюю и верхнюю границы для точность значения с учетом наихудших ошибок точности.

Например, если у вас есть значение в диапазоне [1,0, 2,0] и вычесть из него значение в диапазоне [0,0, 1,0], то результат должен лежать в диапазоне [ниже (0,0), выше (2,0)] так как минимальный результат 1,0-1,0, а максимальный 2,0-0,0. below и above эквивалентны полу и потолку, но для следующего представимого значения, а не для целых чисел.

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

getSlope(
 a = [2.7115599999999995262:2.7115600000000004144], 
 b = [-1.6416099999999997916:-1.6416100000000002357], 
 c = [2.7041299999999997006:2.7041300000000005888], 
 d = [-1.7221899999999998876:-1.7221900000000003317])
(d-b) = [-0.080580000000000526206:-0.080579999999999665783]
(c-a) = [-0.0074300000000007129439:-0.0074299999999989383218]

to double precision [10.845222072677243474:10.845222072679954195]

Таким образом, хотя c-a мало по сравнению с c или a, оно все же велико по сравнению с двойным округлением, поэтому, если вы использовали наихудшее вообразимое округление с двойной точностью, вы могли бы быть уверены, что это значение будет точным до 12 цифр - 10,8452220727. Вы потеряли несколько цифр из-за двойной точности, но вы все еще работаете над значимостью вашего ввода.

Но если бы входные данные были точными только до значащих цифр, то вместо двойного значения 2,71156 +/- eps диапазон ввода был бы [2,711555,2,711565], так что вы получите результат:

getSlope(
 a = [2.711555:2.711565], 
 b = [-1.641615:-1.641605], 
 c = [2.704125:2.704135], 
 d = [-1.722195:-1.722185])
(d-b) = [-0.08059:-0.08057]
(c-a) = [-0.00744:-0.00742]

to specified accuracy [10.82930108:10.86118598]

что является гораздо более широким диапазоном.

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

С другой стороны, если ваши входные данные известны только до 6 цифр, на самом деле не имеет значения, получите ли вы 10,8557 или 10,8452. Оба находятся в пределах [10.82930108:10.86118598].

Аргументы тоже лучше распечатайте. Когда вы, как я предполагаю, передаете параметры в десятичной системе счисления, вы теряете точность для каждого из них. Проблема в том, что 1/5 - это бесконечный ряд в двоичном формате, поэтому, например. 0.2 становится .001001001.... Кроме того, десятичные дроби обрезаются при преобразовании двоичного числа с плавающей запятой в текстовое представление в десятичном формате.

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

Патрик кажется прав насчет (ca) основная причина:

d-b = -1,72219 - (-1,64161) = -0,08058

c-a = 2,70413 - 2,71156 = -0,00743

S = (d-b)/(c-a)= -0,08058 / -0,00743 = 10,845222

Вы начинаете с точностью до шести цифр, с помощью вычитания вы получаете сокращение до 3 и четырех цифр. Мое лучшее предположение состоит в том, что вы теряете дополнительную точность, потому что число -0,00743 не может быть точно представлено в двойном значении. Попробуйте использовать промежуточные переменные с большей точностью, например:

double QSweep::getSlope(double a, double b, double c, double d)
{
    double slope;
    long double temp1, temp2;

    temp1 = (d-b);
    temp2 = (c-a);
    slope = temp1/temp2;

    return slope;
}

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

Это будет иметь некоторые накладные расходы, но вы сможете найти что-то с достаточно гарантированной точностью.