WikiDer > Алгоритм суммирования Кахана - Википедия

В числовой анализ, то Алгоритм суммирования Кахана, также известный как компенсированное суммирование,^[1] значительно снижает числовая ошибка в сумме, полученной добавлением последовательность конечных-точность числа с плавающей запятой, по сравнению с очевидным подходом. Это делается путем сохранения отдельной компенсация бега (переменная для накопления мелких ошибок).

В частности, просто суммируя п числа в последовательности имеют ошибку наихудшего случая, которая растет пропорционально п, а среднеквадратичное значение ошибка, которая растет как ${ displaystyle { sqrt {n}}}$ для случайных входов (ошибки округления образуют случайная прогулка).^[2] При скомпенсированном суммировании оценка ошибки наихудшего случая практически не зависит от п, поэтому большое количество значений может быть суммировано с ошибкой, которая зависит только от числа с плавающей запятой. точность.^[2]

В алгоритм приписывается Уильям Кахан.^[3] Подобные более ранние методы, например, Линейный алгоритм Брезенхема, отслеживая накопленную ошибку в целочисленных операциях (хотя впервые были задокументированы примерно в то же время^[4]) и дельта-сигма модуляция^[5]

Алгоритм

В псевдокод, алгоритм будет;

функция KahanSum (ввод) вар sum = 0.0 // Подготавливаем аккумулятор. вар c = 0.0 // Текущая компенсация потерянных младших битов. за я = 1 к input.length делать     // Массив Вход имеет элементы, проиндексированные input [1] для input [input.length]. вар y = input [i] - c // c равен нулю в первый раз. вар t = sum + y // Увы, сумма большой, у маленькие, поэтому младшие цифры у потеряны. c = (t - сумма) - y // (t - сумма) отменяет высшую часть у; вычитание у восстанавливает отрицательный (низкая часть у) sum = t // Алгебраически c всегда должен быть равен нулю. Остерегайтесь чрезмерно агрессивных оптимизирующих компиляторов! следующий i // В следующий раз потерянная низкая часть будет добавлена ​​к у в новой попытке. возвращаться сумма

Пример работы

Этот пример будет дан в десятичном формате. Компьютеры обычно используют двоичную арифметику, но принцип тот же. Предположим, мы используем шестизначную десятичную арифметику с плавающей запятой, сумма достиг значения 10000.0, а следующие два значения ввод [я] равны 3,14159 и 2,71828. Точный результат - 10005,85987, который округляется до 10005,9. При простом суммировании каждое входящее значение будет выровнено с сумма, и многие цифры младшего разряда будут потеряны (путем усечения или округления). Первый результат после округления будет 10003,1. Второй результат будет 10005,81828 до округления и 10005,8 после округления. Это не так.

Однако при скомпенсированном суммировании мы получаем правильный округленный результат 10005,9.

Предположить, что c имеет начальное значение ноль.

  у = 3,14159 - 0,00000 y = input [i] - c  t = 10000.0 + 3.14159 = 10003.14159 Но сохраняются только шесть цифр. = 10003.1 Многие цифры потеряны! c = (10003.1 - 10000.0) - 3.14159 Это должен оценивать как написано! = 3,10000 - 3,14159 Ассимилированная часть у восстановлено, по сравнению с исходным полным у. = -0.0415900 Конечные нули показаны, потому что это шестизначная арифметика. Сумма = 10003.1 Таким образом, несколько цифр из ввод (я) встретил сумма.

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

  y = 2.71828 - (-0.0415900) Учитывается недостаток предыдущего этапа. = 2.75987 Его размер похож на у: большинство цифр встречаются. t = 10003,1 + 2,75987 Но мало кто встречается с цифрами сумма. = 10005,85987 И результат округляется = 10005,9 до шести цифр. c = (10005.9 - 10003.1) - 2.75987 Это извлекает все, что вошло. = 2.80000 - 2.75987 В данном случае слишком много. = 0,040130 Но независимо от того, в следующий раз избыток будет вычтен. Сумма = 10005,9 Точный результат - 10005,85987, это правильно округлено до 6 цифр.

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

Точность

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

Предположим, что суммируется п значения Икс_я, за я = 1, ... ,п. Точная сумма составляет

${ Displaystyle S_ {п} = сумма _ {я = 1} ^ {п} х_ {я}}$ (вычислено с бесконечной точностью).

При скомпенсированном суммировании вместо этого получаем ${ displaystyle S_ {n} + E_ {n}}$, где ошибка ${ displaystyle E_ {n}}$ ограничен^[2]

${ displaystyle | E_ {n} | leq { big [} 2 varepsilon + O (n varepsilon ^ {2}) { big]} sum _ {i = 1} ^ {n} | x_ { i} |,}$

куда ε это точность станка используемой арифметики (например, ε ≈ 10⁻¹⁶ для стандарта IEEE двойная точность плавающая точка). Обычно интерес представляет собой относительная ошибка ${ displaystyle | E_ {n} | / | S_ {n} |}$, которая поэтому ограничена сверху

${ displaystyle { frac {| E_ {n} |} {| S_ {n} |}} leq { big [} 2 varepsilon + O (n varepsilon ^ {2}) { big]} { frac { sum limits _ {i = 1} ^ {n} | x_ {i} |} { left | sum limits _ {i = 1} ^ {n} x_ {i} right |} }.}$

В выражении для оценки относительной погрешности дробь Σ |Икс_я| / | ΣИкс_я| это номер условия задачи суммирования. По сути, номер условия представляет собой внутренний чувствительность задачи суммирования к ошибкам, независимо от способа ее вычисления.^[6] Граница относительной ошибки каждый (назад стабильный) метод суммирования по фиксированному алгоритму с фиксированной точностью (т.е.не те, которые используют произвольная точность арифметика, ни алгоритмы, чьи требования к памяти и времени меняются в зависимости от данных), не пропорциональны этому числу условия.^[2] An плохо воспитанный В задаче суммирования это отношение велико, и в этом случае даже скомпенсированное суммирование может иметь большую относительную ошибку. Например, если слагаемые Икс_я являются некоррелированными случайными числами с нулевым средним, сумма равна случайная прогулка, а число обусловленности будет расти пропорционально ${ displaystyle { sqrt {n}}}$. С другой стороны, для случайных входов с ненулевым средним асимптотика числа обусловленности стремится к конечной константе при ${ Displaystyle п к infty}$. Если все входы неотрицательный, то номер условия равен 1.

Учитывая число обусловленности, относительная ошибка компенсированного суммирования фактически не зависит от п. В принципе есть O (nε²), который линейно растет с увеличением п, но на практике этот член фактически равен нулю: так как конечный результат округляется до точности ε, то nε² срок округляется до нуля, если только п составляет примерно 1 /ε или больше.^[2] При двойной точности это соответствует п примерно из 10¹⁶, намного больше, чем большинство сумм. Таким образом, для фиксированного числа обусловленности ошибки скомпенсированного суммирования эффективно О(ε), независим отп.

Для сравнения, относительная погрешность наивного суммирования (простое последовательное сложение чисел с округлением на каждом шаге) растет как ${ Displaystyle О ( varepsilon п)}$ умноженное на число условия.^[2] Однако эта ошибка наихудшего случая редко наблюдается на практике, потому что она возникает только в том случае, если все ошибки округления имеют одинаковое направление. На практике гораздо более вероятно, что ошибки округления имеют случайный знак с нулевым средним значением, так что они образуют случайное блуждание; в этом случае наивное суммирование имеет среднеквадратичное значение относительная ошибка, которая растет как ${ displaystyle O left ( varepsilon { sqrt {n}} right)}$ умноженное на число условия.^[7] Однако это все еще намного хуже, чем компенсированное суммирование. Однако если суммирование может быть выполнено с удвоенной точностью, то ε заменяется на ε², а наивное суммирование имеет ошибку наихудшего случая, сравнимую с O (nε²) в скомпенсированном суммировании с исходной точностью.

Точно так же Σ |Икс_я| что появляется в ${ displaystyle E_ {n}}$ выше - это оценка наихудшего случая, которая возникает только в том случае, если все ошибки округления имеют один и тот же знак (и имеют максимально возможную величину).^[2] На практике более вероятно, что ошибки имеют случайный знак, и в этом случае члены в Σ |Икс_я| заменяются случайным блужданием, и в этом случае, даже для случайных входов с нулевым средним, ошибка ${ displaystyle E_ {n}}$ растет только как ${ displaystyle O left ( varepsilon { sqrt {n}} right)}$ (игнорируя nε² срок), так же ставим сумму ${ displaystyle S_ {n}}$ растет, отменяя ${ displaystyle { sqrt {n}}}$ коэффициенты при вычислении относительной ошибки. Таким образом, даже для асимптотически плохо обусловленных сумм относительная ошибка для компенсированного суммирования часто может быть намного меньше, чем можно было бы предположить при анализе наихудшего случая.

Дальнейшие улучшения

Neumaier^[8] представил улучшенную версию алгоритма Кахана, которую он называет «улучшенным алгоритмом Кахана – Бабушки», который также охватывает случай, когда следующий добавляемый член больше по абсолютной величине, чем текущая сумма, эффективно меняя роль того, что является большим а что мало. В псевдокод, алгоритм:

функция NeumaierSum (ввод) вар сумма = 0,0 вар c = 0.0 // Текущая компенсация потерянных младших битов. за я = 1 к input.length делать        вар t = сумма + ввод [i] если | сумма | > = | input [i] | тогда            c + = (sum - t) + input [i] // Если сумма больше, младшие цифры ввод [я] потеряны. еще            c + = (input [i] - t) + sum // Остальные младшие цифры сумма потеряны. endif        сумма = т следующий я возвращаться sum + c // Коррекция применяется только один раз в самом конце.

Для многих последовательностей чисел оба алгоритма согласуются, но простой пример, сделанный Питерсом^[9] показывает, чем они могут отличаться. Для подведения итогов ${ displaystyle [1.0, + 10 ^ {100}, 1.0, -10 ^ {100}]}$ при двойной точности алгоритм Кахана дает 0,0, тогда как алгоритм Ноймайера дает правильное значение 2,0.

Также возможны модификации более высокого порядка с большей точностью. Например, вариант, предложенный Кляйном,^[10] который он назвал «итерационным алгоритмом Кахана – Бабушки второго порядка». В псевдокод, алгоритм:

функция KleinSum (ввод) вар сумма = 0,0 вар cs = 0,0 вар ccs = 0,0 за я = 1 к input.length делать        вар t = сумма + ввод [i] если | сумма | > = | input [i] | тогда            c = (сумма - t) + ввод [i] еще            c = (input [i] - t) + sum endif        сумма = t t = cs + c если | cs | > = | c | тогда            cc = (cs - t) + c еще            cc = (c - t) + cs endif        cs = t ccs = ccs + cc следующий я возвращаться сумма + cs + ccs

Альтернативы

Хотя алгоритм Кахана достигает ${ displaystyle O (1)}$ рост ошибки при суммировании п числа, только немного хуже ${ Displaystyle О ( журнал п)}$ рост может быть достигнут попарное суммирование: один рекурсивно делит набор чисел на две половины, суммирует каждую половину, а затем складывает две суммы.^[2] Это имеет то преимущество, что требует того же количества арифметических операций, что и простое суммирование (в отличие от алгоритма Кахана, который требует в четыре раза больше арифметических операций и имеет задержку, в четыре раза превышающую простое суммирование) и может быть вычислен параллельно. Базовым случаем рекурсии в принципе может быть сумма только одного (или нуля) чисел, но амортизировать накладные расходы на рекурсию, обычно используется более крупный базовый случай. Эквивалент попарного суммирования используется во многих быстрое преобразование Фурье (БПФ) и отвечает за логарифмический рост ошибок округления в этих БПФ.^[11] На практике при ошибках округления случайных знаков среднеквадратичные ошибки попарного суммирования фактически растут как ${ displaystyle O left ({ sqrt { log n}} right)}$.^[7]

Другая альтернатива - использовать арифметика произвольной точности, который в принципе не требует округления вообще с гораздо большими вычислительными затратами. Способ получения точно округленных сумм с использованием произвольной точности - адаптивное расширение с использованием нескольких компонентов с плавающей запятой. Это минимизирует вычислительные затраты в типичных случаях, когда не требуется высокая точность.^[12][9] Другой метод, использующий только целочисленную арифметику, но большой аккумулятор, был описан Кирхнером и Кулиш;^[13] аппаратная реализация была описана Мюллером, Рубом и Рюллингом.^[14]

Возможная недействительность при оптимизации компилятора

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

т = сумма + у;

c = (t - сумма) - y;

к

c = ((сумма + y) - сумма) - y;

а затем в

c = 0;

таким образом устраняется компенсация ошибок.^[15] На практике многие компиляторы не используют правила ассоциативности (которые являются только приблизительными в арифметике с плавающей запятой) в упрощениях, если это явно не указано в параметрах компилятора, включающих «небезопасные» оптимизации,^{[16][17][18][19]} Хотя Компилятор Intel C ++ это один из примеров, который по умолчанию допускает преобразования на основе ассоциативности.^[20] Оригинал K&R C версия Язык программирования C позволил компилятору переупорядочить выражения с плавающей запятой в соответствии с правилами ассоциативности реальной арифметики, но последующие ANSI C стандарт запрещает переупорядочивание, чтобы сделать C более подходящим для числовых приложений (и более похожим на Фортран, который также запрещает повторный заказ),^[21] хотя на практике параметры компилятора могут повторно включить переупорядочение, как упоминалось выше.

Поддержка библиотеками

В общем, встроенные функции «суммы» в компьютерных языках обычно не дают никаких гарантий того, что будет использован конкретный алгоритм суммирования, не говоря уже о суммировании Кахана.^{[нужна цитата]} В BLAS стандарт для линейная алгебра подпрограммы явно избегают предписания какого-либо конкретного вычислительного порядка операций по соображениям производительности,^[22] и реализации BLAS обычно не используют суммирование Кахана.

Стандартная библиотека Python компьютерный язык определяет fsum функция для точно округленного суммирования, используя Шевчук алгоритм^[9] для отслеживания нескольких частичных сумм.

в Юля язык, реализация по умолчанию сумма функция делает попарное суммирование для высокой точности с хорошей производительностью,^[23] но внешняя библиотека предоставляет реализацию варианта Ноймайера с именем сумма_кбн для случаев, когда требуется более высокая точность.^[24]

в C # язык, Пакет HPCsharp nuget реализует вариант Neumaier и попарное суммирование: как скалярные, так и параллельные с использованием данных SIMD инструкции процессора и параллельные многоядерные.^[25]

Смотрите также

• Алгоритмы расчета дисперсии, который включает устойчивое суммирование

Рекомендации

внешняя ссылка

• Суммирование с плавающей запятой, журнал доктора Добба, сентябрь 1996 г.