Различия в округленном результате при вызове pow()

Question

ОК, я знаю, что было много вопросов о функции pow и отбрасывании ее результата в int, но я не мог найти ответ на этот немного конкретный вопрос.

ОК, это код C:

#include <stdio.h> 
#include <stdlib.h> 
#include <math.h> 

int main() 
{ 
    int i = 5; 
    int j = 2; 

    double d1 = pow(i,j); 
    double d2 = pow(5,2); 
    int i1 = (int)d1; 
    int i2 = (int)d2; 
    int i3 = (int)pow(i,j); 
    int i4 = (int)pow(5,2); 

    printf("%d %d %d %d",i1,i2,i3,i4); 

    return 0; 
} 

И это выход: "25 25 24 25". Обратите внимание, что только в третьем случае, когда аргументы pow не являются литералами, мы имеем неправильный результат, вероятно, вызванный ошибками округления. То же самое происходит без явного литья. Может ли кто-нибудь объяснить, что происходит в этих четырех случаях?

Im using CodeBlocks в Windows 7 и компилятор MinGW gcc, который пришел с ним.

Answer 1

Результат операции pow - 25.0000 плюс или минус некоторая ошибка округления. Если ошибка округления положительна или равна нулю, результат преобразования будет равен целому числу. Если ошибка округления отрицательная, результат будет 24. Оба ответа верны.

Что, скорее всего, происходит внутри, так это то, что в одном случае используется более высокое значение 80-битного значения FPU, а в другом случае результат записывается из FPU в память (в виде 64- бит дважды), а затем снова прочитать (преобразование его в немного отличающееся 80-битное значение). Это может сделать микроскопическую разницу в конечном результате, и это все, что требуется, чтобы изменить 25.0000000001 на 24.999999997

Еще одна возможность заключается в том, что ваш компилятор распознает константы, переданные pow, и сам вычисляет, подставляя результат для позвоните по номеру pow. Ваш компилятор может использовать внутреннюю математическую библиотеку с произвольной точностью или просто использовать другую.

Answer 2

Я довольно уверен, что это можно объяснить «промежуточное округлением», и тот факт, что pow не просто обхват вокруг j раз умножая на i, но вычислений с использованием exp(log(i)*j) как вычисление с плавающей запятой. Промежуточное округление может хорошо конвертировать 24.999999999996 в 25.000000000 - даже произвольное хранение и перезагрузка значения могут вызывать различия в такого рода поведении, поэтому в зависимости от того, как генерируется код, это может иметь значение для точного результата.

И, конечно же, в некоторых случаях компилятор может даже «знать», что фактически достигает pow, и заменяет вычисления постоянным результатом.

Answer 3

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

Я настоятельно рекомендую прочитать эту статью (несмотря на то, что это долго читать): http://hal.archives-ouvertes.fr/docs/00/28/14/29/PDF/floating-point-article.pdf

Перейти к разделу 3 для практических примеров, но не пренебрегайте предыдущие главы!

Answer 4

Это обусловлено сочетанием двух задач:

• Реализация pow вы используете не высокого качества. Арифметика с плавающей запятой обязательно является приблизительной во многих случаях, но хорошие реализации заботятся о том, чтобы простые случаи, такие как pow(5, 2), возвращали точные результаты.Используемый вами pow возвращает результат, который меньше 25 на сумму больше 0, но меньше или равен 2 ^-49. Например, он может возвращать 25-2 ^-50.
• Реализация C, которую вы используете, иногда использует 64-битный формат с плавающей запятой и иногда использует 80-битный формат с плавающей запятой. Пока номер сохраняется в 80-битном формате, он сохраняет полное значение, возвращаемое pow. Если вы преобразуете это значение в целое число, оно выдает 24, потому что значение меньше 25 и преобразование в целые усечения; он не круглый. Когда число преобразуется в 64-битный формат, оно округляется. Преобразование между раундами форматов с плавающей точкой, поэтому результат округляется до ближайшего представляемого значения 25. После этого преобразование в целое число создает 25.

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

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