Почему результат этого явного приведения отличается от неявного?
#include <stdio.h>
double a;
double b;
double c;
long d;
double e;
int main() {
a = 1.0;
b = 2.0;
c = .1;
d = (b - a + c) / c;
printf("%li\n", d); // 10
e = (b - a + c) / c;
d = (long) e;
printf("%li\n", d); // 11
}
Если я делаю d = (long) ((b - a + c)/c); Я также получаю 10. Почему назначение двойника имеет значение?
Я подозреваю, что разница заключается в преобразовании из 80-битного значения с плавающей запятой в длинное и преобразование из 80-битного значения с плавающей запятой в 64-битное, а затем преобразование в длинное.
(Причина появления 80 бит - это то, что типичная точность используется для фактической арифметики и ширины регистров с плавающей запятой.)
Предположим, что 80-битный результат - это что-то вроде 10.999999999999999 - переход от этого к длинному урожаю 10. Однако ближайшее 64-битное значение с плавающей запятой до 80-битного значения на самом деле составляет 11,0, поэтому двухэтапное преобразование заканчивается тем, что дает 11.
РЕДАКТИРОВАТЬ: дать этому немного больше веса...
Здесь программа Java, которая использует арифметику произвольной точности для выполнения одного и того же вычисления. Обратите внимание, что он преобразует двойное значение, самое близкое к 0,1, в BigDecimal - это значение равно 0,1000000000000000055511151231257827021181583404541015625. (Другими словами, точный результат вычисления не равно 11).
import java.math.*;
public class Test
{
public static void main(String[] args)
{
BigDecimal c = new BigDecimal(0.1d);
BigDecimal a = new BigDecimal(1d);
BigDecimal b = new BigDecimal(2d);
BigDecimal result = b.subtract(a)
.add(c)
.divide(c, 40, RoundingMode.FLOOR);
System.out.println(result);
}
}
Здесь результат:
10.9999999999999994448884876874217606030632
Другими словами, это исправление примерно до 40 десятичных цифр (может обрабатывать не более 64 или 80 бит с плавающей запятой).
Теперь рассмотрим, как выглядит это число в двоичном формате. У меня нет инструментов для простого преобразования, но мы снова можем использовать Java. Предполагая нормализованное число, часть "10" заканчивается использованием трех бит (один меньше, чем одиннадцать = 1011). Это оставляет 60 бит мантиссы для расширенной точности (80 бит) и 48 бит для двойной точности (64 бит).
Итак, что самое близкое число до 11 в каждой точности? Опять же, позвольте использовать Java:
import java.math.*;
public class Test
{
public static void main(String[] args)
{
BigDecimal half = new BigDecimal("0.5");
BigDecimal eleven = new BigDecimal(11);
System.out.println(eleven.subtract(half.pow(60)));
System.out.println(eleven.subtract(half.pow(48)));
}
}
Результаты:
10.999999999999999999132638262011596452794037759304046630859375
10.999999999999996447286321199499070644378662109375
Итак, три числа, которые у нас есть:
Correct value: 10.999999999999999444888487687421760603063...
11-2^(-60): 10.999999999999999999132638262011596452794037759304046630859375
11-2^(-48): 10.999999999999996447286321199499070644378662109375
Теперь выведите самое близкое значение к правильному для каждой точности - для расширенной точности - менее 11. Разобьте каждое из этих значений на длинное, и вы получите соответственно 10 и 11.
Надеюсь, этого достаточно, чтобы убедить сомневающихся;)
Я получаю 10 и 11 на моей 32-разрядной Linux-системе x86 с запуском gcc 4.3.2.
Соответствующий C/asm находится здесь:
26:foo.c **** d = (b - a + c) / c;
42 .loc 1 26 0
43 0031 DD050000 fldl b
43 0000
44 0037 DD050000 fldl a
44 0000
45 003d DEE9 fsubrp %st, %st(1)
46 003f DD050000 fldl c
46 0000
47 0045 DEC1 faddp %st, %st(1)
48 0047 DD050000 fldl c
48 0000
49 004d DEF9 fdivrp %st, %st(1)
50 004f D97DFA fnstcw -6(%ebp)
51 0052 0FB745FA movzwl -6(%ebp), %eax
52 0056 B40C movb $12, %ah
53 0058 668945F8 movw %ax, -8(%ebp)
54 005c D96DF8 fldcw -8(%ebp)
55 005f DB5DF4 fistpl -12(%ebp)
56 0062 D96DFA fldcw -6(%ebp)
57 0065 8B45F4 movl -12(%ebp), %eax
58 0068 A3000000 movl %eax, d
58 00
27:foo.c ****
28:foo.c **** printf("%li\n", d);
59 .loc 1 28 0
60 006d A1000000 movl d, %eax
60 00
61 0072 89442404 movl %eax, 4(%esp)
62 0076 C7042400 movl $.LC3, (%esp)
62 000000
63 007d E8FCFFFF call printf
63 FF
29:foo.c **** // 10
30:foo.c ****
31:foo.c **** e = (b - a + c) / c;
64 .loc 1 31 0
65 0082 DD050000 fldl b
65 0000
66 0088 DD050000 fldl a
66 0000
67 008e DEE9 fsubrp %st, %st(1)
68 0090 DD050000 fldl c
68 0000
69 0096 DEC1 faddp %st, %st(1)
70 0098 DD050000 fldl c
70 0000
71 009e DEF9 fdivrp %st, %st(1)
72 00a0 DD1D0000 fstpl e
72 0000
32:foo.c ****
33:foo.c **** d = (long) e;
73 .loc 1 33 0
74 00a6 DD050000 fldl e
74 0000
75 00ac D97DFA fnstcw -6(%ebp)
76 00af 0FB745FA movzwl -6(%ebp), %eax
77 00b3 B40C movb $12, %ah
78 00b5 668945F8 movw %ax, -8(%ebp)
79 00b9 D96DF8 fldcw -8(%ebp)
80 00bc DB5DF4 fistpl -12(%ebp)
81 00bf D96DFA fldcw -6(%ebp)
82 00c2 8B45F4 movl -12(%ebp), %eax
83 00c5 A3000000 movl %eax, d
83 00
Ответ оставлен как упражнение для заинтересованного читателя.
codepad.org(gcc 4.1.2) отменяет результаты вашего примера, тогда как в моей локальной системе (gcc 4.3.2) я получаю 11 в обоих случаях. Это говорит о том, что это проблема с плавающей точкой. В качестве альтернативы теоретически можно усечь (b - a + c), который в целочисленном контексте будет оценивать (2 - 1 + 0)/.1, что будет 10, тогда как в контексте с плавающей точкой (2.0 - 1.0 + 0.1 )/.1 = 1.1/.1 = 11. Это было бы странно, хотя.
Прямая копия/вставка и компиляция на Linux дает мне 11 для обоих. Добавление d = (long) ((b - a + c) / c); также дает 11. То же самое происходит и с OpenBSD.
Вот куча деталей о проблемах с плавающей запятой и действительно хорошая статья. Но в принципе, не все значения с плавающей запятой могут быть представлены на определенное количество бит (32 бит или 64 бит или что-то еще). Это глубокий вопрос, но мне нравится, потому что он напоминает мне Prof. Каган.:)