double сохраняет данные не в точном виде. Нужен ли тип данных, который будет сохранять все знаки после запятой в точном виде? - страница 4
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Приведите пример специализированных финансовых приложений, где используется более длинный формат данных, чем double. Даже в бухгалтерских программах всегда производится округление. Представьте себе годовой баланс с кучей знаков после запятой. Ну или например, компания задолжала налогов на 0.000000001 копейки. Нонсенс? А почему тогда в трейдинге это не нонсенс? Точных расчётов всё равно не бывает кроме тех случаев, когда целые числа складываются или вычитаются. Значит, надо округлять, делая это сообразно с задачами, которые нам интересны. И ещё важный момент. Для расчётных задач нужно применять формат данных, который требует минимум преобразований из одного формата в другой, т.к. уже на этом этапе могут возникать ошибки. Ну вот хотя бы арифметический сопроцессор может работать как с 64-битными, так и с 80-битными данным и. Но преобразования между ними - времяёмкий процесс с неизбежной потерей точности. Оптимизация софта это ещё и минимизация числа преобразований между данными.
Округляют конечный результат, а не данные при каждой математической операции.
Определиться с точностью с которой надо это делать и после каждого сложения нормализовать.
так работает
просто немного неудобно каждый раз эти даблы нормализировать.
и всегда помнить, когда их используешь, что там может всплыть ошибка. и всегда стараться все прописать так, чтобы ошибка не появилась.
просто нормализовать всегда даблы, когда пишешь код, немного неудобно.
Пиши, пиши класс CDecimal. Оно и проще и полезней будет.
в топике имеется в виду BCD ? двоично-десятичная арифметика, ранее (а возможно и сейчас) применяемая в бухгалтерии ??
какой-же он новый. В процессорах до сих сохраняются (для совместимости) соответсвующие инструкции. Но потеря точности от переходов на double мизерна, а выигрыш в скорости и портабельности существеннен.
разве не лучше работать с точными числами, чем с неточными?
Исходное значение цены имеет 5 знаков после запятой, double имеет 15 знаков после запятой. После 8 знака можно все отбросить как ошибку. Планируйте вычисления исходя из исходных значений и наслаждайтесь жизнью.
Кстати, в экселе тоже накапливается погрешность.
Но там если суммировать числа типа 1/3, 1/6 ...
Вот что будет если 10 000 раз прибавить число 1/3.
хотя должно быть 3333.33333333333333
ну вот, голимые ваши даблы. а если использовать decimel, ошибки бы там не появилось. )))
Ну вы даёте. Попробуйте разделить 10$ на три равных части. Погрешность будет. Если делать точно, то надо всё хранить в разного рода дробях и математических выражений. Мы ведь что-то рассчитываем, верно)?
а в дабловых и при сложении, и вычитании. да и сами они изначально уже с погрешностью.)