double сохраняет данные не в точном виде. Нужен ли тип данных, который будет сохранять все знаки после запятой в точном виде? - страница 5
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Ну вы даёте. Попробуйте разделить 10$ на три равных части. Погрешность будет. Если делать точно, то надо всё хранить в разного рода дробях и математических выражений. Мы ведь что-то рассчитываем, верно)?
3 + 1/3
в троичной системе - конечная дробь
:-)
да. в десятичных там при делении иногда бывает погрешность.
а в дабловых и при сложении, и вычитании. да и сами они изначально уже с погрешностью.)
да. в десятичных там при делении иногда бывает погрешность.
а в дабловых и при сложении, и вычитании. да и сами они изначально уже с погрешностью.)
Компьютер-то двоичный. В нем уже 0.1 - бесконечная периодическая дробь, обрезанная по размеру мантиссы. Собственно, из-за деления на 5, деление на 2 не порождает бесконечных дробей, 0.125 (1/2^3) в компьютере очень короткое число. Так что изначально, аппаратно, погрешность появляется именно из-за непредставимости десятичных дробей в неродном, двоичном виде.
Друзья, нет смысла в расчетах оперировать числами, таская за собой числа с разрядностью большей чем у исходных данных. Это всё равно, что учитывать блох при взвешивании слонов. Загуглите "Теория погрешностей" и убедитесь. Если на Форексе цены представлены числами с 5 знаками после запятой, то все результаты вычислений на их основе никак не могут получаться точнее этих исходных данных. сколько бы мы не использовали знаков после запятой во всех промежуточных действиях. Лишние цифры называются незначащими. Поэтому для наших расчетов в советниках и индикаторах вполне хватит точности типа float. Тип double вообще нет смысла применять, и тем более городить что-то вроде типа decimal.
У вас рассчёты ограничены сложением и вычитанием?
реже умножение и деление.
Компьютер-то двоичный. В нем уже 0.1 - бесконечная периодическая дробь, обрезанная по размеру мантиссы. Собственно, из-за деления на 5, деление на 2 не порождает бесконечных дробей, 0.125 (1/2^3) в компьютере очень короткое число. Так что изначально, аппаратно, погрешность появляется именно из-за непредставимости десятичных дробей в неродном, двоичном виде.
чаще всего эти 2 операции.
реже умножение и деление.
а в децимал (в переводе: десятичная дробь) как оно там всё устроено, что оно нормально представляет числа в десятичном виде?
Никто двоичную природу компьютеров из-за работы, в частности, с деньгами, переделывать не будет. Представлять десятичные числа корректно Вы и сами легко сможете, используя округление. Просто надо решить, как быть с умножением и делением, результат которых часто выходит за границы заданного формата, строковое представление не вмещает все разряды, надо отбрасывать, округлять. Чисто индивидуальное решение. Вместо Вас его никто не примет, дело не в показе строки.
Один мой знакомый в 1991-92 годах писал программу для начислений (сейчас счетов-фактур) по ЖКХ для района, где жили больше 200 тысяч человек. Смеялся, рассказывая, как можно было решать задачу округления. В квитанциях ведь и статей затрат было с десяток, то есть 2 млн. округлений до копейки, 10 тыс. рублей, кому достанется?
Подробнее, как внутри: устройство FPU ВИКИ "Математический сопроцессор", почти всеобщий стандарт представления в нем чисел "IEEE 754-2008" (там описаны 5 вариантов округления, уже имеющихся в FPU). Представление decimal в СУБД реализуется программно.
Смеялся, рассказывая, как можно было решать задачу округления. В квитанциях ведь и статей затрат было с десяток, то есть 2 млн. округлений до копейки, 10 тыс. рублей, кому достанется?
а что, он всегда округлял в меньшую сторону?
Представление decimal в СУБД реализуется программно.
https://habr.com/company/xakep/blog/257897/