100, можно гарантировать что оно никогда не превратится во что-то вроде 123.999999999?
это особенности float, так что гарантировать нельзя
промежуточные буду округлять с помощью ceil, а сумму с помощью round и вроде все ОК должно быть
если у тебя известно сколько цифр после запятой (например, цена товара), то лучше считать все как int, а после делить на 100
Можно гарантировать, что превратится
Только? Поделите столбиком 10/9.. ;)
очевидно) только в задаче, насколько я понял, не предполагается деление, а только лишь сложение
сложение и умножение
Сложение и умножение не приводят нив какой системе счисления к нерациональным числам.. насколько помню теорию за первый курс.. проблема в машинном переводе из десятичной в двоичную системы и обратно,т.к. операции имеют под капотом деление. Для корректных вычислений двоично-десятичная арифметика и 4-х разрядные системы.. ;) ну или десимал, что и есть вычисления в целых числах со сдвигом. Только умножать надо не на 100, а на кратно двум.. ;)
вы далеко что-то пошли....
стандартная практика - хранить деньги в микроцентах (микрокопейках) плохо работает с сатоши 🙂 (одной бирже пришлось на int128 перейти)
есть еще экзотически валюты где это тоже не работает Мальти́йский ску́до (итал. scudo maltese) — денежная единица Мальтийского ордена. Скудо = 12 тари = 240 грано.
к иррациональным не приводят, но страшна не только иррациональность, но также периодичность записей
ну и храните в микро-грано. В целом идея в том чтобы считать в долях наименьших единиц где-то в районе 12 знака после запятой чтобы нивелировать округления.
ну вот конкретно в моем случае, должны быть math.Ceil и они должны накапливаться
я не вчитывался в ваш код, но для всяких систем есть рекомендации регуляторов как правильно считать и что делать при расчетах (налоговики, центробанк), какое округление использовать в каких случаях.
да! есть такое
Обсуждают сегодня