|
22.04.2019, 00:02 | #1 |
Участник
|
Ошибка сложения больших чисел.
Уж не знаю куда пихнуть этот баг.
То ли смеяться, то ли плакать. И совсем не знаю как это лечить... От слова СОВСЕМ. Смотрим во вложенном файле на сумму и умиляемся, всплескиваем руками, улыбаемся и машем.... |
|
22.04.2019, 07:33 | #2 |
Участник
|
Ну не умеет excel с большими числами работать
Только подкручивать Excel. Например, есть надстройка расчеты с большими числами, но она только с целочисленными работает нормально. Для плавающей надо смотреть, пилить. |
|
22.04.2019, 09:34 | #3 |
Участник
|
Ну и в чем проблема ?
Это же везде такое будет не только в Excel Посмотрите на это с другой стороны. Максимальное число во вложении 144395647983495 ошибка -0,002812500 погрешность 2*10^-17 по-моему очень неплохой результат. Если все же нужно копейки как-то ловить, то возможно поможет такой прием - напишите макрос - свою функцию суммирования. а в ней перед суммированием сперва складывается самый большие по модулю числа. Тогда получается точный 0. пример во вложении |
|
22.04.2019, 09:56 | #4 |
Участник
|
Числа формируются в процессе выполнения программы.
Изменить порядок поступления чисел в суммирование нельзя. только если навешивать дополнительный контейнер, в который собирать эти числа, ранжировать их и только потом суммировать. В общем, проблема на ровном месте. |
|
22.04.2019, 10:39 | #5 |
Участник
|
"Не баг, но фича" (с) Причем для большинства продуктов Microsoft это настройка по умолчанию
Системные ограничения Excel Точность представления чисел, разрядов, не более = 15 разрядов Цитата с другого форума Цитата:
Внутри себя (...) представляет числа в формате double - можешь почитать MSDN по поводу этого формата и его точности. Если по простому говорить, то формат предусматривает для ЗНАЧИМОЙ части числа всего 53 бита (один неявный), а, соответственно, переводя из двоичной системы, получаем что эти 53 бита позволяют хранить
53*LOG(2)/LOG(10) т.е. примерно 15.9546 десятичных разряда Как уже было сказано, тупо Excel не предназначен для работы с такими большими числами. Результаты арифметических операций с плавающей точкой в Excel могут быть неточными
__________________
- Может, я как-то неправильно живу?! - Отчего же? Правильно. Только зря... Последний раз редактировалось Владимир Максимов; 22.04.2019 в 11:14. |
|
22.04.2019, 21:42 | #6 |
Banned
|
Проверил в LibreOffice, то же самое. То есть это не MS, а более широкая проблема.
Что считаем кстати? Полет на Mарс? Цифры нереально большие. |
|
23.04.2019, 10:10 | #7 |
Участник
|
Цитата:
То есть это не MS, а более широкая проблема.
__________________
Я прибыл к вам из Кантемировской дивизии. А там, как известно, дураков не держат! |
|
23.04.2019, 18:13 | #8 |
Banned
|
Цитата:
Сообщение от БАХ43
Конечно не MS. Скорее Intel. Количество бит в байте, количество байт для хранения числа, разрядность процессора. Просто разработчики железа в свое время решили, что этого будет достаточно. А для расчета полета на Марс используйте ЕС ЭВМ с двоично-десятичным представлением больших чисел и фортран с его обширными математическими библиотеками.
Это просто следование стандарту IEEE Standard for Floating-Point Arithmetic (IEEE 754) https://en.wikipedia.org/wiki/IEEE_754 Не баг, а фича. |
|
24.04.2019, 09:51 | #9 |
Участник
|
Цитата:
Это просто следование стандарту IEEE Standard for Floating-Point Arithmetic (IEEE 754)
__________________
Я прибыл к вам из Кантемировской дивизии. А там, как известно, дураков не держат! |
|
23.04.2019, 10:33 | #10 |
Участник
|
Есть тип decimal
Можно было его попробовать привинтить в Excel |
|