(Untitled)

[dmih]

Чтобы закрыть тему foat-ов, разовью еще немного 0.9(9) = 1 и фобию по поводу "аааа страшная потеря точности" в виде 0.9999999998765

Comments

[wizzard0]

Оо, по ссылке есть статья 96 года с клевым округлятором, спасибо.

[dmih]

"Printing Floating-Point Numbers Quickly and Accurately" офигительная, да!

[dmih]

Хотя для начала и без матана программистам хорошо бы просто запомнить, что нельзя смотреть на float-ы глазами, как я в прошлом посте написал.

[buddy_ekb]

как-то с годами начинаешь без особого содрогания смотреть на такие вот косяки (ой, а он не знает из чего float собран, и вообще * шарашит в много-JOIN-овые SELECT'ы, "ну а чо, работает же!").

ну не знает кто-то конкретной частной проблемы - не беда, главное, чтобы этот некто из конкретной ошибки умел делать своевременные и правильные выводы.
лучше, конечно, если это будут выводы из чужих ошибок, но не всем и не всегда так везёт.

в любом случае, ремесло программиста предполагает знание достаточно большого числа явных и неявных зависимостей и невозможно заранее предсказать, насколько быстро человек использует или усваивает опыт, применимый (зачастую) лишь при решении конкретного класса задач.

по теме - ну явно же неразумно использовать в биллинге ни длинные, ни короткие decimal, ни float'ы всех мастей.
использовать надо GNU MP и его аналоги, но это вообще отдельный холивар, да ещё и связанный с хранением промежуточных значений во внешних хранилищах (привет, SQL).

[dmih]

Мы сейчас так договоримся до того, что программисту не надо знать, как int устроен.

[buddy_ekb]

ха. применительно к биллингу - именно, что не нужно программисту знать как устроены int и long на его любимой платформе и ему бы лучше знать ПБУ.

[dmih]

Я наверное частично соглашусь в том смсысле, что незнание ПБУ приводит к еще более странным биллингам, чем незнание программирования :)

[spiculator]

Надо в rational хранить, тогда вообще на всё можно положить. Никаких действий, кроме отнять-сложить-умножить-разделить, в биллинге в принципе быть не может. Хотя при сложении дробей с разными делителями результат может получиться некрасивый, на этот случай применяем вместо int'а бескончный int, как там он называется. :)

[spiculator]

Жалко, что акт нельзя выставить на 14+3/31 р.

[dmih]

1/31 с 1/30 и 1/28 и 1/29 очень уж некрасиво складывается.
Сразу наступит такой ад, что неясно, в чем недостаток хранить просто сразу с эпсилон-точностью, где эпсилон доказанно устраивает :)

[spiculator]

Всего-то четыре разных делителя, наименьшее общее кратное -- четыреста тысяч, в long влезет. :)

[dmarck]

Эмм, я тупой тормоз или почему никто на numeric не ссылается?

[dmih]

Есть соседний пост, где тема раскрыта лучше - http://amarao-san.livejournal.com/2944300.html

[dmarck]

Да я вроде бы все три прочитал, и продолжаю недоумённо крутить носом ;)

[dmih]

Да нет разницы между numeric/decimal(фикс точка, основание 10) и float(плав.точка, основание 2).
Либо мы храним дроби, либо нет.
Если храним, реализация в любом случае замысловатая и примерно одинаковая для всех методов.
Если нет, реализация простая, но тогда получается не биллинг, а простите говно.

[schors]

Я видимо туповат, но я так и не понял, чего ты до моих костылей с подневной тарификацией докопался.

P.S. Всё перечитал - всё равно не понял

[dmih]

Из эстетических соображений.
Вообще я так понимаю у тебя это вспомогательная система всё-таки, с таким можно жить, это легкая шиза.