booby,

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

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

Альтернативную идею можно сформулировать так:
1) образуй частичные суммы
2) складывай между собой такие частичные суммы, которые испытали до этого одно и то же количество сложений.

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

Общего между ними то, что в обоих случаях образуется двоичное дерево вычислений одной и той же высоты.
Общее число сложенных элементов определяется как 2 в степени высоты дерева.
Высота 64 достаточна для сложения 2**64 слагаемых, что выглядит как с большим запасом достаточное количество для использования в обычных базах данных (18 446 744 073 709 551 616 слагаемых).
64 - это оценка максимальной глубины рекурсии попарного сложения, построенного на рекурсивном методе "разделяй и властвуй", и это же оценка необходимого количества "ячеек" дополнительной памяти, в которые складываются частичные суммы во втором методе.
То есть использование дополнительного массива в 64 элемента обеспечивает достаточно
места для сложения результатов, определяемых частичными суммами, испытавшими одно и то
же число сложений. этот массив можно назвать "счетчиком сложений", хранящим результаты самих частичных сложений - т.е. простейшими счетами - абаком, в ячейки которого складываются частичные суммы.

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

Сейчас набросал вариант реализации для binary_double чисел, для которых алгоритмы подомного сорта и предназначены.

Определим на схеме коллекцию числе binary_double:


Работу счетчика сложим в объект:



Параметр p_carry процедуры put в норме возвращает ноль.
Как только он вернул не ноль, это значит, что разрядной сетки счетчика не хватило
для поддержки высоты вычисления, и с полученным числом вызывающий клиент дальше
должен обходиться самостоятельно - разрядная сетка счетчика переполнилась.

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

Этот вариант настолько же лучше попарного сложения, насколько менее известен и совсем не описан в публичных википедиях.

PS1
Почему использовал название "сложение по Кислицину"

На ютубе как-то набрел на ролики, обсуждающие алгоритм Кислицина поиска наименьшего и следующего за ним наименьшего, упоминаемый в 17 томе УМН 1962г. (Успехи математических наук) в заметках о заседаниях Ленинградского математического общества.
(сам алгоритм в УМН не приводится, но дается асимптотическая оценка его сложности).
Двоичный счетчик существенно используется в том алгоритме, но в более сложном конструктивном исполнении.
Мимоходом при обсуждении в ролике на ютубе сказано, что с такими счетчиками можно делать много полезных вещей, простейшей из которых является сложение чисел с плавающей точкой с хорошими статистическими характеристиками и по скорости нарастания ошибки
и по общей производительности.

Т.е., в своей идее, это уже очень старый алгоритм.
Возможно уже "ненужный" или даже "бесполезный" в контексте обнаружения метода Ноймайера.

За сим из топика выхожу.

PS2
надеюсь, топикстартер не сильно обижен за такое замусоривание его топика.

Elic,

может быть не заметил, но вообще единственным сообщением по теме, в топике был пост от Тролин.
После него в этом топике остается только плясать и веселиться, а ты на людей бросаешься...

На месте Oracle и я бы заявил, что это not a bug - кто же будет менять математику, работавшую столько десятков лет,
да и созданную задолго до формирования подходящих к случаю стандартов.
Воспроизводимость повторного вычисления важнее.

Конечно, совет про round(,20) от них читается с неизбывным впечатлением о том, что ты опять попал на sql.ru
Но содержательно выбор не так велик - либо кастовать число к raw и копать там про необходимость округления граничной цифры,
раз уж это не сделали разработчики библиотечной математики, либо просто обзавестись подходящим к случаю двухфазным округлением.

для себя когда-то я сваял, как раз по аналогичному случаю, такую функцию:


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

iOracleDev,

вы не прочитали - мною функция не обсуждается.

Proteus... ( я конечно не понял их идеи о проверке расчета той же формулой но ничего не докажешь )
ты же в первом посте написал:
Выражение меняет значение при изменении последовательности его вычисления

написанное пером не вырубается топором.
У тебя нет свободы выбора.
У клиента тоже нет.
вопрос лишь в том, чья несвобода напористей.