Различные результаты в режимах отладки и выпуска - PullRequest
4 голосов
/ 21 июня 2011
vector<double> pvec;

double firstnode=0.0;

for(iter2=svec.begin(); iter2!=svec.end(); iter2++)
{
    double price= 0.0;
    string sFiyat = iter2->substr(13);
    stringstream(sFiyat)>>price;
    price=log(price);

    if (iter2==iter)
    {
        firstnode = price;
    }
    price -= firstnode;

    pvec.push_back(price);
}

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

В режиме отладки это дает желаемый результат, и первый элемент вектора всегда равен нулю. Но когда я переключаюсь в режим выпуска, первый элемент вектора равен некоторому небольшому числу, например 8.86335e-019.

И это еще не все. Когда я поставил строку "cout << цена << endl;" после строки "цена = журнал (цена);" тогда результат, который я получил от версии выпуска, такой же, как и в режиме отладки. Есть объяснения? </p>

Ответы [ 3 ]

6 голосов
/ 21 июня 2011

Стек отладочной плавающей запятой использует полную 80-битную точность, доступную в FPU. Режимы выпуска работают на более эффективных 64-битных усеченных результатах.

Измените ваше поведение с плавающей точкой, чтобы оно было независимым при сборке, с помощью / fp http://msdn.microsoft.com/en-us/library/e7s85ffb%28VS.80%29.aspx См. Также http://thetweaker.wordpress.com/2009/08/28/debugrelease-numerical-differences/

Некоторые из наблюдаемых различий просто связаны с точностью отображения. Убедитесь, что для cout установлена ​​полная точность, прежде чем сравнивать его со значением, отображаемым отладчиком MSVC.

2 голосов
/ 21 июня 2011

Попробуйте отключить оптимизацию в вашей сборке релиза ...

1 голос
/ 21 июня 2011

Когда вы используете вычисления с плавающей запятой, ошибка порядка 8e-19 настолько близка к нулю, насколько вы получаете.

У вас есть ошибка, которая составляет менее одной миллиардной части от расчетного значения. Это довольно близко!

...