Здравствуйте, Кодт, Вы писали: К>Здравствуйте, __kot2, Вы писали: __>>когда разговор заходит про ньюансы округления, то это обычно финансы. деньги. специально для этого есть тип decimal, просто забудьть про double и все. К>Можно просто считать в копейках.
вы просто отодвинете проблему на большие суммы, всего на два порядка.
Здравствуйте, _DAle_, Вы писали:
_DA>Иногда можно и обычным long обойтись.
С long есть маленькая проблемка
123*100/118 != 123/118*100
С decimal с необходимым числом знаков после точки всё проще, но и там следует осознавать когда нужно округлять и какие эффекты могут проявиться. Точно так же как и с double.
Здравствуйте, SL, Вы писали:
SL>В целом да с финансами, насчет Fixed point floating это понятно, но интересно Excel тоже использует Fixed point floating арифметику, потому что если в нем в трех ячейках вбить цифры 2625, 0.18, 100 и в четвертой указать операцию с тремя ячейками то есть (2625.0 * 0.18)/100 и указать в формате два знака после запятой, то Excel выводит 4.73.
Скорее всего.
В double ты никогда точно не округлишь — т.е. конечно могут быть числа, которые точно представимы в формате double, но это только в отдельных частных случаях.
double принято округлять при выводе пользователю (кстати, возможно, что Excel и так поступает)
Здравствуйте, pagid, Вы писали:
_DA>>Иногда можно и обычным long обойтись.
P>С long есть маленькая проблемка
P>123*100/118 != 123/118*100
Нет проблемы, просто часть бит нужно отвести под дробную часть с нужной чточностью, и не забывать нормализовывать.
с double кстати, такая же фигня скорее всего
P>С decimal с необходимым числом знаков после точки всё проще, но и там следует осознавать когда нужно округлять и какие эффекты могут проявиться. Точно так же как и с double.
Здравствуйте, Marty, Вы писали:
M>Нет проблемы, просто часть бит нужно отвести под дробную часть с нужной чточностью, и не забывать нормализовывать.
Тогда мы вернемся по кругу в начало разговора и к вопросу ТС
M>с double кстати, такая же фигня скорее всего
+1
M>Да вообще всегда нужно понимать, что делаешь
+1
Здравствуйте, SL, Вы писали:
SL>округляется до 4.72 и вроде понятна причина число 4.725 на самом деле представляет собой 4.729999999999999, но не могу понять как побороть.
Скорее всего "бороть" и не нужно. Округлятся должно при выводе на экран/печать и библиотечные функции поступают именно так. Если программа работает с БД, и речь идет про деньги, то можно убедится, что при сохранении в субдешную DECIMAL происходит именно округление, но вроде по стандарту SQL это так.
Использование чего-то подобного decimal из С# тоже вариант, но полезность этого стоит оценить, пока из того, что ты написал необходимость так извращаться не очевидна.
Перекуём баги на фичи!
