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

[Вадим Зыков]

К нам стали поступать вопросы по поводу правильности расчета итоговых значений в таблицах.

Хотели бы немного прояснить ситуацию.

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

Складывать округленные слагаемые нельзя, это приведет к накапливаемому искажению данных. Это можно проиллюстрировать примером десяти слагаемых по 0.1 каждое.

Точные значения:
0.1
0.1
...
0.1
Итого 1.0

Допустим, нормативный документ требует округления до целых значений. Получим:
0
0
...
0
Итого 1

Сумма, как видите, не бьется со слагаемыми, и это правильно.

Очевидно недопустимо потребовать в такой ситуации показать сумму 0.

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

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

Коллеги, как вы предлагаете нам поступать в такой ситуации?

[Panzerkampfwagen]

Сделать настройки округления в ВАШИХ программах единообразными и одинаковыми. А сейчас вместо этого пытаетесь узнать у нас иной вариант, поскольку этот ВАС не устраивает. Сколько с ВАШИМИ специалистами разбирались на эту тему, ни одного внятного решения не добились, что говорит о их и вашей квалификации как компании.
Вы проблемы не исправляете, а замалчиваете.
Или делаете вид что не поняли их суть.
Или рассказываете про ваш "опыт" и "квалификацию".
И свобода слова у вас тут процветает на форуме, когда просто не публикуете не понравившиеся сообщения или вопросы.

[Вадим Зыков]

Panzerkampfwagen, по всей видимости у вас есть недопонимания сути проблемы. Округление как раз единообразное.

Позвольте еще раз подчеркнуть ключевые моменты:

1. Программа использует точные значения параметров для расчетов, но в отчетах выводит округленные значения промежуточных данных и результатов. Делается это согласно выставленной пользователем настройки.
2. Сумма округленных слагаемых в строке "Итого" не будет точно совпадать с суммой точных значений. Это не является ошибкой, а следствием правил округления.
3. Складывать округленные слагаемые недопустимо, так как это приведет к накапливаемым ошибкам округления. Правильный подход - складывать точные значения, а затем округлять итоговую сумму.
4. Если требуется определенная точность представления итоговой суммы, то и исходные слагаемые следует вводить с такой же точностью. Это позволит минимизировать ошибки округления.
5. Требовать отображения суммы 0 в случае округления десяти слагаемых по 0.1 до целых значений было бы некорректно, так как это не соответствует математической логике.

Округления не всегда являются линейными. Это важный момент, который стоит учитывать в данной ситуации.

В этом случае сумма округленных значений не равна округленному значению суммы. Такие ситуации могут возникать довольно часто.

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

Учет нелинейности округлений является ключевым моментом при объяснении корректности расчетов в подобных ситуациях.

Мы по-прежнему готовы прислушаться к конструктивным предложениям.

[DDim]

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

ну, вероятно, вот и надо перед тем как суммировать в программе, округлять суммируемые числа до нужного знака. Важен же результат – чтоб в таблице в графе итого (всего) было значение, равное сумме всех чисел по строкам этой таблицы.
А как это реализовывать - это уже вам сами решать. Отдельно хранить округленные значения, "на лету" округлять или ещё как (я не специалист, не знаю) - это не к пользователю )

[Кирилл Честнов]

DDim, то есть все-таки суммировать округленные слагаемые? И в приведенном примере показывать 0 + 0 + ... + 0 = 0, зная про себя, что на самом деле 1?

[DDim]

Кирилл Честнов, ну да - если пользователь задал такое округление ))
я так понимаю, основная проблема в том, что у проверяющих (в экспертизе, например, или может ещё где) возникают вопросы к таблицам: они берут суммируют построчно и получают иное значение.

[Кирилл Честнов]

DDim, так и есть. Вы за примерно такую настройку в программе:

«В выходных таблицах в качестве суммы значений по строкам указывать:
— округленную сумму точных слагаемых (этот вариант будет выбран по умолчанию)
либо
— сумму округленных слагаемых»

?

[kentavrik]

округленных слагаемых

А зачем округлять слагаемые? Почему бы их не округлить "с запасом", если точность к итоговой сумме предъявляется до какого там знака? (не помню требований НПА на эту тему), до седьмого? то вот взять и слагаемые "округлять" до 9.
а вообще во всех серьезных выкладках в результатах пишут величину ошибки+/- столько-то, которую программа там или професоор математики :) должен высчитать, учитывая погрешность тех величин которые участвовали в расчете (мы их часто и сами не представляем, когда заводим данные в УПРЗУ, но всё же...).

Отправлено спустя 1 минуту 10 секунд:
а после указания ошибки ещё и доверительнeльную вероятность указывают для этого суждения. :)

[Вадим Зыков]

kentavrik, в приказе Минприроды РФ №871, последний абзац п. 43

При документировании результатов инвентаризации выбросов значения максимального разового (г/с) и валового (т/г) выброса загрязняющих веществ допускается указывать с тремя значащими цифрами после запятой, при этом может использоваться экспоненциальная запись: для г/с - менее 10 и для т/г - менее 10.

Вещества разные бывают. 0301 или 0703. У одного 1,123, а у другого 0,000000000123

а вообще во всех серьезных выкладках в результатах пишут величину ошибки+/-

Очень глубоко капаете.

они берут суммируют построчно и получают иное значение.

Именно так. Если честно, то не очень понятен смысл этой проверки. Тем более, нам присылали примеры, когда отказы получали, если сумма не сходилась в 7, 8 знаке после запятой.

Да и excel не идеальный инструмент. Запишите, например, в одну ячейку =10.5-10.4=0.1 и получите ложь, а не истину.

[kentavrik]

5. Требовать отображения суммы 0 в случае округления десяти слагаемых по 0.1 до целых значений было бы некорректно, так как это не соответствует математической логике.

и п. 43 не соответствует, там же речь идет про 3 значащих значения.

Годовой выброс как сказано в п. 43 рассчитывать? Как сумму годовых выбросов каждого ИЗАВ. А что будет годовым выбросом? Цифры в мозгах программы или цифры из табличек, утверждаемых РПНом или представляемых инвентаризатором за печатью, наверное все таки из табличек. И если смысл суммировать более точные значения, если все равно норматив дается на ИЗАВ и сравнивать факт будут с персональной ячейкой. И это ... в этом п. 43 нигде же не сказано, что точность и разрядность суммы должна быть идентична нормативам на каждый ИЗАВ.

Тем более, нам присылали примеры, когда отказы получали, если сумма не сходилась в 7, 8 знаке после запятой.

я то сначала вообще в заголовок рубрики в которой тема не посмотрел, думал речь идет о таблицах отчетов рассеивания.
А по нормативам я сам помню получал несколько отказов в те времена когда занимался разрешениями на выброс. Приходилось вручную таблички делать, использовать функцию в эксэль "точность как на экране". Думаю что эксперты правы в том что хотят добиться исполнения Закона, предпоследнего абзаца п. 43. И думаю что сумма сходиться должна со слагаемыми из таблицы из-за этого Закона, но вот "Всего" надо как раз и округлять до третьей значащей цифры (так оно чаще сходится будет). Или если уж чтоб всегда сходилось, то наверное вот надо программу научить складывать округленные слагаемые, думаю экологии урона от этого не будет.