Почему изменение порядка сумм возвращает другой результат?

Почему изменение порядка сумм возвращает другой результат?

23.53 + 5.88 + 17.64 знак равно 47.05

23.53 + 17.64 + 5.88 знак равно 47.050000000000004

И Java, и JavaScript возвращают одинаковые результаты.

Я понимаю, что из-за того, что числа с плавающей запятой представлены в двоичном виде, некоторые рациональные числа ( например, 1/3 - 0,333333 ... ) не могут быть представлены точно.

Почему простое изменение порядка элементов влияет на результат?

Может быть, этот вопрос глуп, но почему простое изменение порядка элементов влияет на результат?

Это изменит точки, в которых значения округлены, в зависимости от их величины. В качестве примера рода вещей , которые мы видят, давайте делать вид , что вместо бинарной с плавающей точкой, мы использовали десятичный тип с плавающей точкой с 4 значащими цифрами, где выполняются каждое добавление в «бесконечной» точности , а затем с округлением до ближайшее представимое число. Вот две суммы:

1/3 + 2/3 + 2/3 = (0.3333 + 0.6667) + 0.6667
                = 1.000 + 0.6667 (no rounding needed!)
                = 1.667 (where 1.6667 is rounded to 1.667)

2/3 + 2/3 + 1/3 = (0.6667 + 0.6667) + 0.3333
                = 1.333 + 0.3333 (where 1.3334 is rounded to 1.333)
                = 1.666 (where 1.6663 is rounded to 1.666)

Нам даже не нужны нецелые числа, чтобы это было проблемой:

10000 + 1 - 10000 = (10000 + 1) - 10000
                  = 10000 - 10000 (where 10001 is rounded to 10000)
                  = 0

10000 - 10000 + 1 = (10000 - 10000) + 1
                  = 0 + 1
                  = 1

Возможно, это более четко демонстрирует, что важной частью является то, что у нас ограниченное количество значащих цифр, а не ограниченное количество десятичных знаков . Если бы мы всегда могли сохранить одинаковое количество десятичных разрядов, то, по крайней мере, с добавлением и вычитанием мы были бы в порядке (до тех пор, пока значения не переполняются). Проблема в том, что когда вы получаете большее число, меньшая информация теряется - 10001 округляется до 10000 в этом случае. (Это пример проблемы, которую Эрик Липперт отметил в своем ответе .)

Важно отметить, что значения в первой строке с правой стороны одинаковы во всех случаях - поэтому, хотя важно понимать, что ваши десятичные числа (23.53, 5.88, 17.64) не будут представлены точно как doubleзначения, это только проблема из-за проблем, показанных выше.

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

С помощью этой программы я вывожу шестнадцатеричные представления каждого числа и результаты каждого сложения.

public class Main{
   public static void main(String args[]) {
      double x = 23.53;   // Inexact representation
      double y = 5.88;    // Inexact representation
      double z = 17.64;   // Inexact representation
      double s = 47.05;   // What math tells us the sum should be; still inexact

      printValueAndInHex(x);
      printValueAndInHex(y);
      printValueAndInHex(z);
      printValueAndInHex(s);

      System.out.println("--------");

      double t1 = x + y;
      printValueAndInHex(t1);
      t1 = t1 + z;
      printValueAndInHex(t1);

      System.out.println("--------");

      double t2 = x + z;
      printValueAndInHex(t2);
      t2 = t2 + y;
      printValueAndInHex(t2);
   }

   private static void printValueAndInHex(double d)
   {
      System.out.println(Long.toHexString(Double.doubleToLongBits(d)) + ": " + d);
   }
}

printValueAndInHexМетод просто помощник шестигранного принтера.

Вывод следующий:

403787ae147ae148: 23.53
4017851eb851eb85: 5.88
4031a3d70a3d70a4: 17.64
4047866666666666: 47.05
--------
403d68f5c28f5c29: 29.41
4047866666666666: 47.05
--------
404495c28f5c28f6: 41.17
4047866666666667: 47.050000000000004

Первые 4 цифры x, y, z, и s«ы шестнадцатеричные представления. В представлении IEEE с плавающей запятой биты 2-12 представляют двоичный показатель , то есть масштаб числа. (Первый бит является знаковым битом, а остальные биты для мантиссы .) Представленная экспонента фактически является двоичным числом минус 1023.

Экспоненты для первых 4 чисел извлекаются:

    sign|exponent
403 => 0|100 0000 0011| => 1027 - 1023 = 4
401 => 0|100 0000 0001| => 1025 - 1023 = 2
403 => 0|100 0000 0011| => 1027 - 1023 = 4
404 => 0|100 0000 0100| => 1028 - 1023 = 5

Первый набор дополнений

Второе число ( y) имеет меньшую величину. При сложении этих двух чисел x + yпоследние 2 бита второго числа ( 01) сдвигаются за пределы диапазона и не учитываются при расчете.

Второе дополнение добавляет x + yи zдобавляет два числа одного масштаба.

Второй набор дополнений

Здесь x + zпроисходит первое. Они имеют одинаковый масштаб, но они дают число, которое выше в масштабе:

404 => 0|100 0000 0100| => 1028 - 1023 = 5

Второе дополнение добавляет x + zи y, и теперь 3 бита отбрасываются yдля добавления чисел ( 101). Здесь должен быть округлен вверх, потому что результатом является следующее число с плавающей запятой вверх: 4047866666666666для первого набора дополнений по сравнению 4047866666666667со вторым набором дополнений. Эта ошибка достаточно значительна, чтобы показать ее в распечатке.

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

Ответ Джона, конечно, правильный. В вашем случае ошибка не превышает ошибку, которую вы накапливаете, выполняя любую простую операцию с плавающей запятой. У вас есть сценарий, в котором в одном случае вы получаете нулевую ошибку, а в другом - крошечную ошибку; это не очень интересный сценарий. Хороший вопрос: существуют ли сценарии, в которых изменение порядка вычислений превращается из крошечной ошибки в (относительно) огромную ошибку? Ответ однозначно да.

Рассмотрим для примера:

x1 = (a - b) + (c - d) + (e - f) + (g - h);

против

x2 = (a + c + e + g) - (b + d + f + h);

против

x3 = a - b + c - d + e - f + g - h;

Очевидно, в точной арифметике они будут одинаковыми. Интересно попытаться найти значения для a, b, c, d, e, f, g, h так, чтобы значения x1 и x2 и x3 отличались в большом количестве. Посмотри, сможешь ли ты сделать это!

На самом деле это охватывает гораздо больше, чем просто Java и Javascript, и, вероятно, повлияет на любой язык программирования с использованием чисел с плавающей запятой или двойных чисел.

В памяти плавающие точки используют специальный формат в соответствии со стандартом IEEE 754 (конвертер дает гораздо лучшее объяснение, чем я).

В любом случае, вот конвертер поплавков.

http://www.h-schmidt.net/FloatConverter/

Дело в порядке операций - «тонкость» операции.

Ваша первая строка дает 29,41 из первых двух значений, что дает нам 2 ^ 4 в качестве показателя степени.

Ваша вторая строка дает 41,17, что дает нам 2 ^ 5 в качестве показателя степени.

Мы теряем значительную цифру, увеличивая показатель степени, что может изменить результат.

Попробуйте включить и выключить последний бит в дальнем правом углу для 41.17, и вы увидите, что чего-то «незначительного», такого как 1/2 ^ 23 от показателя степени, будет достаточно, чтобы вызвать эту разницу с плавающей запятой.

Изменить: Для тех из вас, кто помнит значимые цифры, это подпадает под эту категорию. 10 ^ 4 + 4999 со значащей цифрой 1 будет 10 ^ 4. В этом случае значимая цифра намного меньше, но мы можем видеть результаты с прикрепленным к ней .00000000004.

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

В вашем случае происходит то, что во втором случае сложение, вероятно, приводит к некоторой проблеме точности из-за порядка, в котором оцениваются дополнения. Я не вычислял значения, но это может быть, например, то, что 23,53 + 17,64 нельзя точно представить, а 23,53 + 5,88 можно.

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

Я считаю, что это связано с порядком эвакуации. Хотя в математическом мире сумма, естественно, одинакова, в бинарном мире вместо A + B + C = D она

A + B = E
E + C = D(1)

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

Когда вы меняете заказ,

A + C = F
F + B = D(2)