2011-01-27 2 views
4

Я заметил проблему с точностью до двойной двойной версии sqrt(). Следующий код демонстрирует проблему.точность long double sqrt()

#include <iostream> 
#include <cmath> 
#include <cfloat> 

int main(int argc, char ** argv) 
{ 
    int count=0; 
    long double s=sqrt(3L); 
    std::cout.precision(21); 
    std::cout << "s=" << s << ", s^2=" << s*s << std::endl; 
    while(s*s<3L+LDBL_EPSILON) { 
    s+=LDBL_EPSILON; 
    std::cout << s << ' ' << s*s << std::endl; 
    ++count; 
    } 
    std::cout << "sqrt(3L) is approximately " << count << " multiples of LDBL_EPSILON away from the correct value." << std::endl; 
    return 0; 
} 

Компиляция и запуск этого с

>g++ -o sqrt sqrt.cpp && ./sqrt 

дает

s=1.73205080756887719318, s^2=2.9999999999999996524 
1.73205080756887719329 2.99999999999999965284 
1.73205080756887719339 2.99999999999999965306 
... (922 lines omitted) 
1.73205080756887729347 2.99999999999999999978 
1.73205080756887729357 3.00000000000000000022 
sqrt(3L) is approximately 926 multiples of LDBL_EPSILON away from the correct value. 

Регулярный двойной версии SQRT() дает двойной ближе к реальной стоимости.

Версия г ++ я использую

>g++ -v 
Using built-in specs. 
Target: x86_64-linux-gnu 
Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.5-8' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.4 --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --with-arch-32=i586 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu 
Thread model: posix 
gcc version 4.4.5 (Debian 4.4.5-8) 

Это известная ошибка? Должен ли я сообщить об этом где-нибудь?

ответ

9

У вас есть две проблемы: во-первых, 3L неявно способствует double не long double так что даже если вы присвоите возвращаемое значение long double он все еще использует низкую точность версии sqrt. В качестве аргумента вам понадобится static_cast 3 до long double. Во-вторых, только double версия sqrt импортируется в глобальное пространство имен, потому что перегрузка функций не поддерживается в C, вместо этого вы должны использовать std::sqrt.

Таким образом:

long double s=std::sqrt(static_cast<long double>(3));

+0

А, да, это была проблема. Спасибо. :-) –

+3

Нет броска: 3.0L –

0

Является ли значение из «обычной» версии double sqrt() испытывает большую детализацию округления, чем длинный двойной? Это то, чего мы ожидаем. Может быть, это «гранулярное» округление оказывается близким к правильному значению - ближе, чем длинный двойной sqrt.

Способ проверить это было бы попробовать несколько значений и сравнить.

+0

с небольшим изменением в коде, чтобы отрегулировать значение с помощью коэффициента 1 + LDBL_EPSILON или 1-LDBL_EPSILON, я проверил точность SQRT() с 2 , 3, 5 и 11. В каждом случае двойной sqrt() дал правильный результат, а длинный двойной sqrt() был отключен на значительную сумму - требуя 892 умножения на 1-LDBL_EPSILON в случае sqrt (2L), чтобы получить самое точное значение! –

Смежные вопросы