и дальше больше

Мы понимаем. Как это влияет на расчёт цен, которые пользователь должен оплатить или вернуть пользователю? Таких дробей там просто не будет (а в моей модели и дробей не нужно)

Может ошибаюсь, но кажется это звучит так: «Дорогой бизнес, мы взяли технологию, у которой из коробки чего-то там нету, а взять bigdecimal который работает поверх массивов/строк - забыли, поэтому тебе точность не нужна, и если что - выкидывай все и нанимай клятых джавистов/гошников/etc”. Не то, чтобы это плохо по моему опыту, ведь такие подходы генерируют в дальнейшем рабочие места и возможности мемов/ баек :)

Не "технологию", а модель. Это во-первых. Во-вторых, в модели нет вашего любимого “округления" (да, в реализации - но реализация не нарушает модель - опровергните?)

Так даже если в округление не лазить, флоат еще как-то закостылять вприпципе можно для 7 значащих цифр, дабл - 15 вроде. А все что за пределами этого, неизбежно ведёт к ошибкам в расчетах.

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

Велком найти ошибки в модели. Если работать со флоатом без использования моих функций, то ссзб

Как бы сказать, здесь фундаментальная дыра, и даже совсем ненужно тратить время на поиски конкретных контр-промеров, чтобы понять это. Это как с парсингом html-а регэкспами, кто-то рвётся в бой и думает что оно работает, а потом оказывается, что html физически не обрабатывается таким вычислителем :) А всего-то надо применить теорию формальных языков… (Тьюринг полнота отсюда же)

вообще если правильно округлять то все будет красиво )

И теза Чёрча. А мы о чём вообще? Модель корректна?

В рамках определенного количества значащих цифр - может быть корректной, и не стрелять проблемами :) И кажется это речь про 15 значащих цифр, точно не больше. Там скорее можно дать гарантии на проблемы.

Я не видел цен на сайтах, где 15 знаков нужны в ценах)

Сложная история, это как с часовыми поясами, мало кто видел, что сдвиг может быть не кратен часу, даже не кратен получасу, а он есть!)

Тут важно отметить, что работа со временем имеет отдельную модель. Я её не пытался реализовать. Советую прочитать https://zachholman.com/talk/utc-is-enough-for-everyone-right
Особенно про изменённую дату в одной стране)))
Тут вопрос о другом совсем

Изначально речь именно о том, что есть фундаментальные ограничения при работе с плавающей точкой, а помимо ограничений - неизбежные костыли и хаки, в которых тоже можно накосячить. И вот именно эта совокупность вызывает соответствующую реакцию, как минимум у тех, кто ежедневно крутится около финансов :)

Так успокойтесь.

О, боже, опять не читаете модель - там нет ничего про флоаты, акститесь! (Опять дрочат на реализацию)

Можно ж вот на эту тему потрындеть например

а мне вот интересно, кто как решает вопрос с клиент-сайд роутингом (кажется это так называется) ивентов
ну то есть лучшее, к чему я пришёл - это писать if-ы в обработчике событий
Например есть какая-то штука, к которой привязан пользователь, у штуки есть статусы, у пользователя есть роли
Происходит событие - статус поменялся, а дальше есть правила, например
1. Обрабатывать события только о переходах в какой-то определённый статус штуки (тут можно в каких-то ситуациях делать ивенты разных типов, но не уверен, что оно всегда стоит того)
2. Обрабатывать только если к штуке привязан пользователь с определённой ролью

Ну к примеру это элементарные оповещения на имейл могут быть. Типа если штука перешла в статус такой-то, то оповещаем пользователя привязанного к этой штуке с этими вот ролями

И 3 знака это тоже оверкил ага