- 1
- 2
- 3
- 4
- 5
- 6
x1 = x1 * 1000;
x2 = x2 * 1000;
int i = (int) Math.round(x1);
int i2 = (int) Math.round(x2);
x1 = (double) i / 1000;
x2 = (double) i2 / 1000;
Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
−39
x1 = x1 * 1000;
x2 = x2 * 1000;
int i = (int) Math.round(x1);
int i2 = (int) Math.round(x2);
x1 = (double) i / 1000;
x2 = (double) i2 / 1000;
Ограничиваем вывод тремя знаками после запятой
gost 03.11.2015 20:25 # +1
*В среде тех, кто не знает про String.format
Dummy00001 04.11.2015 12:46 # +1
в одной финансовой системе подобный трюк делался что бы отрезать малозначимые цифры после н-ой позиции.
bormand 04.11.2015 12:47 # +7
> double
Dummy00001 04.11.2015 13:43 # 0
arbitrary precision числа просто в жопу тормозят. в паре мест народ пробовал - но потом выкинули. и не совсем они уже и такие arbitrary: те либы которые я смотрел (какие уже не помню, gmp?) точность можно просто конфигурировать.
bormand 04.11.2015 13:57 # 0
Ну дык это и есть arbitrary. Т.е. именно та точность, которая требуется в твоей задаче, а не диктуемая процессором/компилятором/библиотекой.
Dummy00001 04.11.2015 15:04 # 0
и она не диктуется "процессором/компилятором/библиотекой", а стандартом IEEE 754.
я тоже возмущался. и только после того как работу поменял, столкнулся с arbitrary precision либама. думал что что-то улучшат. на тестах которые гонял, по сравнению с даблом погрешность стабильно была меньше 1e-10. а работают в десятки разов медленее. я был весьма разочарован. и обрадован что дабла хватает и парится не надо.
bormand 05.11.2015 18:13 # +1
Вот из-за таких горе-оптимизаторов людям потом и приходят счета на 0 рублей 00 копеек...
Dummy00001 05.11.2015 18:24 # +1
bormand 05.11.2015 18:32 # 0
Я не знаю, как даблы в финансовые расчёты вообще допустили.
Dummy00001 05.11.2015 18:47 # 0
Это оно так было в моем проекте. Но у меня там большинство было копеешные расчеты. Почему округление и делалось: когда например из 25 центов вычитаешь 7.5% какой скидки, а потом налагаешь 11% налога, числа получаются совсем не круглые.
Большие финансовые пакеты (типа того же asset depreciation) пользуются fixed'ами, подобно тому что реализуют теже RDBMSы. (Банковский софт я не знаю чем пользуется - от них числа всегда строками в XML приходили/к ним уходили.) Но им как бы и не надо десятки миллионов транзакций в час обрабатывать, и как правило извратов с мелкими суммами и/или с налогами тоже не надо делать. (И даже в банковском софте, где у тебя может быть и есть миллионы транзакций, транзакции в real-time не обрабатываются - они аккумулируют батчи, и их по мере накопления обрабатывают.)
bormand 05.11.2015 19:08 # 0
А они точно упираются не в парсинг, не в сеть, не в диск, а в сраную арифметику?
Dummy00001 05.11.2015 19:16 # 0
Но архитекты говорили, что тормозит порядочно. И самое главное: конкуреты тоже даблами пользуются. Поэтому - без шансов.
bormand 05.11.2015 19:17 # 0
Dummy00001 05.11.2015 19:26 # 0
ЗЫ что делают на биржах, я бы с удовольствием послушал. только ХЕЗ где найдешь потому что все обложено "trade secret".
bormand 05.11.2015 19:37 # +1
Так вот кто писал эти алгоритмы!
У моего друга забавная история была... Был у него подключен "любимый номер" для девушки. А потом он подключил анлим. В итоге все звонки по 0р (за счёт анлима), а звонки девушке по 0.5 * тариф (за счёт любимого номера). Кто-то ифы не в том порядке поставил :3
defecate-plusplus 05.11.2015 19:44 # +2
Dummy00001 05.11.2015 19:46 # +4
3_14dar 06.11.2015 00:01 # 0
Dummy00001 04.11.2015 12:47 # +1
bormand 04.11.2015 12:48 # +2
Dummy00001 04.11.2015 13:38 # 0
imihajlov 05.11.2015 10:32 # +2