˸A
Когда начинал писать - нет. Но когда увидел, что получилось)))
ЗЫ: если долго смотреть на этот код, то он начинает смотреть в тебя)
ЗЫ: если долго смотреть на этот код, то он начинает смотреть в тебя)
Size: a a a
2021 June 26
ST
Полностью поддерживаю. Нужен некий аналог decimal - фиксированного дробного числа типа с 4 знаками после запятой. Иначе финотчеты "не бьются" по итогам в колонках с выводимыми в них значениями
˸A
У меня в доке есть отсылки на другие решения. В мадженте, как раз, 4 знака - и это не спасает их от ошибок округления https://magento.stackexchange.com/questions/225168/magento1-9-paypal-rounding-amount-issue
DP
@mkusher , я по поводу заявок и спецификации - проверки на новый агрегат еще раз.
Заявку можно создать
Над заявкой можно проводить разные действия.
Для того, чтобы таких ситуация не случалось можно разделить на два контекста
Менеджмент заявок
И еще один (не смог придумать название), через который идет создание.
Заявку можно создать
Над заявкой можно проводить разные действия.
Для того, чтобы таких ситуация не случалось можно разделить на два контекста
Менеджмент заявок
И еще один (не смог придумать название), через который идет создание.
ST
Так и должно быть, полностью от ошибок округления избавиться нельзя (типовой случай - расчет НДС по колонкам), но можно избавиться от элементарных ошибок.
DE
Избавиться можно, если использовать дроби
˸A
Смотря, какая модель подсчётов. В моей модели нет места "дробным прайсам"
Кстати, любителям считать всё только в целых числах - в джс нету отдельного флоата, как в пыхе - там всё намбер. И 16.90*100 !== 1690
Кстати, любителям считать всё только в целых числах - в джс нету отдельного флоата, как в пыхе - там всё намбер. И 16.90*100 !== 1690
˸A
Я бы посмотрел, как вы эти "дроби" отправляете на payment system provider (PSP), например, PayPal
Каждый инвойс, рефанд и войд - должен иметь конкретную сумму в деньгах, не дробную)))
Каждый инвойс, рефанд и войд - должен иметь конкретную сумму в деньгах, не дробную)))
DE
Отправлять результирующее значение. А все внутренние хранения и промежуточные вычисления можно производить дробями.
˸A
Окей. Можно, наверное... Но моя модель не основана на дробях, и там не нужно бороться с ошибками округления
Наверное, если на дробях, то будет вероятность того, что два рефанда на цент больше/меньше инвойса (вы ведь каждый округлили для PSP)
Наверное, если на дробях, то будет вероятность того, что два рефанда на цент больше/меньше инвойса (вы ведь каждый округлили для PSP)
ST
Где использовать, в документах?
SP
дроби тоже могут переполниться. дроби хорошо работают там где есть общий знаменатель, в периодических процессах, например для позиционирования в чпу )
SP
при сложении дробей где знаменатели будут простыми числами у вас будет мгновенное переполнение
ST
Обсуждаемая проблема не в переполнении, а в несоответствии точности представления и точности хранения.
SP
получаете переполнение - убиваете точность
SP
вернее вы впринципе уходите из безошибочных расчетов. т.е. невозможность сложить дроби это ошибка
DE
Большие вычисления работают со строками в столбик
˸A
Думаю, к расчёту денег это мало относится
ST
Еще раз, проблема не в простых дробях или double, а в представлении.
Внутри - три величины, неважно по 1/3 рубля или по 0,3(3). Представление - три цены по 33 копейки. В итоге по колонке должно стоять 99 копеек, а не 1 рубль.
Внутри - три величины, неважно по 1/3 рубля или по 0,3(3). Представление - три цены по 33 копейки. В итоге по колонке должно стоять 99 копеек, а не 1 рубль.
SP
ну вы понимаете что сложив столько рублей вы уже начитаете выходить на инты?
In [8]: Fraction(1,3557) + Fraction(1,3559) + Fraction(1,3571) + Fraction(1,3541) + Fraction(1,3539)
Out[8]: Fraction(797148104090641, 566510798800541527)
In [8]: Fraction(1,3557) + Fraction(1,3559) + Fraction(1,3571) + Fraction(1,3541) + Fraction(1,3539)
Out[8]: Fraction(797148104090641, 566510798800541527)