Как уже упомянули выше, для частной компании цель получения прибыль необязательна (в отличии от коммерческой).
Существует куча разновидностей частных некоммерческих компаний, начиная прям с вашего ТСЖ (если оно у вас есть). Ну или если брать пример помасштабнее — ФРС.
Мне кажется, хороший менеджер тоже должен уметь решать difficult задачи. В конце концов, на самом высоком уровне задача коммерческой компании в конкурентной среде тоже difficult — «заработать денег».
Задача менеджеров — перевести эту difficult задачу в инженерные difficult задачи. Чем меньше менеджер способен комфортно работать с этими двумя неопределенностями, тем больше он пытается на своём уровне разбить все на компоненты и процедуры, выстроить дисциплину и жёсткие процессы. Удаётся не всегда.
Инженерам, к слову, тоже стоит помнить о неопределенности вышестоящих задач. А то иногда получается так, что «мы тут все такие творческие и непредсказуемые, нам нужен гибкий процесс, но точную спецификацию того, что нужно будет бизнесу через год, извольте предоставить! Нам же нужно заранее спроектировать красивую архитектуру, а не костыли лепить!»
Нужно быть недалеким закомплексованным хамлом, чтобы пренебрежительно относиться к людям, посвятившим жизнь любимому делу (любому), вместо того чтобы рваться в бизнесмены или менеджеры среднего звена.
Кстати, если вас задел мой комментарий, просто скажите себе: «этот человек ошибается, он сам глуп, и здесь нет повода для расстройства или обиды.»
Prop десков в крупных банках имхо не осталось (спасибо Volcker rule), только хежд фонды. Даже в относительно либеральном cash fx приходится натягивать pre-hedging на глобус чтобы как-то оправдать сам факт наличия ненулевой позиции (если банк большой и хранит кучу пенсий европейских старушек).
Но я бы на месте автора не особо заморачивался с ультра-быстрым HFT. Его тучные годы давно прошли, про FPGA и microwave все в целом знают, и сейчас нужно искать баланс между гибкостью и скоростью. Не факт что этот баланс лежит в области наносекунд. Хотя чисто технически наносекунды конечно интересны и впечатляющи.
Мне очень жаль, что вас огорчило нарушение Open-closed principle в библиотеке из 2 классов без планов расширения.
Ваши замечания насчёт getScale и ArithmeticException противоречат требованиям, из-за которых проект был создан. У меня сложилось впечатление, что вы эти требования не понимаете.
Желаю вам и дальше пребывать в уверенности, что все Java программы должны писаться по одному шаблону и для похожих целей. А все что не укладывается в привычные рамки — трэш и говнокод.
Вашу оценку моей квалификации оставлю без комментариев.
Случайные тесты vs BigDecimal у меня бежали где-то неделю на 2 ядрах (домашняя машина). С юнит-тестами хорошая идея, попробую найти в OpenJDK и позаимствовать.
Реализация JavaMoney на Гитхабе (jsr354-ri) использует BigDecimal внутри. Навскидку — в методе divide. Почему мне не подходит BigDecimal я уже писал. Если вы знаете другую реализацию — поделитесь.
умножать только числа с порядком не больше половины максимального
Нет, умножать/делить/etc можно любые числа при условии что результат вместе с дробной частью влезает в long. Если не влезает, возвращается NaN, который легко проверить. Напомню, Java в случае переполнения типа Long.MAX_VALUE * 10 вообще возвращает мусор.
Ваш первый пример — переполнение (18 нулей до запятой и 4 после):
Насчет "вы уверены?". 100% гарантию отсутствия багов я дать не могу, как и большиство разработчиков. Но класс достаточно хорошо оттестирован, в том числе и на граничных случаях. Если вы нашли конкретную проблему, нет ничего проще написать падающий юнит-тест и прислать мне, я буду очень признателен. У библиотеки нет зависимостей, можно просто скопировать 2 класса из Гитхаба в любой пакет.
Я категорически не приветствую написание велосипедов, но моя исходная задача не решалась стандартными средствами, поэтому пришлось писать по-своему.
Утверждение "любые велосипеды содержат больше багов чем любые не-велосипеды" некорректно.
У меня поддерживаются все режимы округления из BigDecimal. Но я бы не сказал, что главная фича это прирост производительности. Цель была — мутабельный и неаллоцирующий класс. Если этого не требуется, то вполне разумно использовать стандартные средства
По-сути так и делается для N=2. Но иногда требуется делить копейки на какие-нибудь центы (чтобы получить курс обмена) и результат должен содержать больше 2 знаков после запятой. Класс просто позволяет работать с разными точностями.
Это не перевод. Я понимаю, что «запятая» по-русски правильнее. Но во большинстве языков программирования мы используем точку. И я решил, что если буду использовать в одной статье «floating point», «плавающая запятая», «1.23» (в коде) и «1,23» (не в коде), то я запутаюсь сам и запутаю остальных. Я думаю, что ИТ-сообщество вполне привыкло к англицизмам в русских технических текстах, в том числе и к «точке».
Да, я как-то замерял switch-case на 9 константных делителей vs обычное деление — switch сильно быстрее. Но тут их не 9, а 128, так что хз. Может сработает, а может загнётся кэш инструкций и будет грузить каждое конкретное деление из ОЗУ за те же десятки наносекунд.
IEEE действительно странный, допускает как BCD, так и binary. Может они заложились на гипотетическую платформу, которая с BCD работает не сильно медленнее. Нормализовывать десятичную точку все-таки удобнее в BCD.
Вычисления в decimal floating point действительно более «привычные» для человека, хотя остаётся проблема с округлением (10^64 + 10^-64 — 10^64 == 0). Основная проблема с ними — производительность, любое сложение/вычитание с разными экспонентами требует деления на степень десятки, что на порядок медленнее обычного сложения.
Как уже упомянули выше, для частной компании цель получения прибыль необязательна (в отличии от коммерческой).
Существует куча разновидностей частных некоммерческих компаний, начиная прям с вашего ТСЖ (если оно у вас есть). Ну или если брать пример помасштабнее — ФРС.
Мне кажется, хороший менеджер тоже должен уметь решать difficult задачи. В конце концов, на самом высоком уровне задача коммерческой компании в конкурентной среде тоже difficult — «заработать денег».
Задача менеджеров — перевести эту difficult задачу в инженерные difficult задачи. Чем меньше менеджер способен комфортно работать с этими двумя неопределенностями, тем больше он пытается на своём уровне разбить все на компоненты и процедуры, выстроить дисциплину и жёсткие процессы. Удаётся не всегда.
Инженерам, к слову, тоже стоит помнить о неопределенности вышестоящих задач. А то иногда получается так, что «мы тут все такие творческие и непредсказуемые, нам нужен гибкий процесс, но точную спецификацию того, что нужно будет бизнесу через год, извольте предоставить! Нам же нужно заранее спроектировать красивую архитектуру, а не костыли лепить!»
Нужно быть недалеким закомплексованным хамлом, чтобы пренебрежительно относиться к людям, посвятившим жизнь любимому делу (любому), вместо того чтобы рваться в бизнесмены или менеджеры среднего звена.
Кстати, если вас задел мой комментарий, просто скажите себе: «этот человек ошибается, он сам глуп, и здесь нет повода для расстройства или обиды.»
Prop десков в крупных банках имхо не осталось (спасибо Volcker rule), только хежд фонды. Даже в относительно либеральном cash fx приходится натягивать pre-hedging на глобус чтобы как-то оправдать сам факт наличия ненулевой позиции (если банк большой и хранит кучу пенсий европейских старушек).
Но я бы на месте автора не особо заморачивался с ультра-быстрым HFT. Его тучные годы давно прошли, про FPGA и microwave все в целом знают, и сейчас нужно искать баланс между гибкостью и скоростью. Не факт что этот баланс лежит в области наносекунд. Хотя чисто технически наносекунды конечно интересны и впечатляющи.
Мне очень жаль, что вас огорчило нарушение Open-closed principle в библиотеке из 2 классов без планов расширения.
Ваши замечания насчёт getScale и ArithmeticException противоречат требованиям, из-за которых проект был создан. У меня сложилось впечатление, что вы эти требования не понимаете.
Желаю вам и дальше пребывать в уверенности, что все Java программы должны писаться по одному шаблону и для похожих целей. А все что не укладывается в привычные рамки — трэш и говнокод.
Вашу оценку моей квалификации оставлю без комментариев.
Реализация JavaMoney на Гитхабе (jsr354-ri) использует BigDecimal внутри. Навскидку — в методе divide. Почему мне не подходит BigDecimal я уже писал. Если вы знаете другую реализацию — поделитесь.
Один маленький падающий юнит-тест, вместо долгих рассуждений на тему «это не заработает»
Нет, умножать/делить/etc можно любые числа при условии что результат вместе с дробной частью влезает в long. Если не влезает, возвращается NaN, который легко проверить. Напомню, Java в случае переполнения типа Long.MAX_VALUE * 10 вообще возвращает мусор.
Ваш первый пример — переполнение (18 нулей до запятой и 4 после):
Ваш второй пример работает нормально:
Насчет "вы уверены?". 100% гарантию отсутствия багов я дать не могу, как и большиство разработчиков. Но класс достаточно хорошо оттестирован, в том числе и на граничных случаях. Если вы нашли конкретную проблему, нет ничего проще написать падающий юнит-тест и прислать мне, я буду очень признателен. У библиотеки нет зависимостей, можно просто скопировать 2 класса из Гитхаба в любой пакет.
Я категорически не приветствую написание велосипедов, но моя исходная задача не решалась стандартными средствами, поэтому пришлось писать по-своему.
Утверждение "любые велосипеды содержат больше багов чем любые не-велосипеды" некорректно.
IEEE действительно странный, допускает как BCD, так и binary. Может они заложились на гипотетическую платформу, которая с BCD работает не сильно медленнее. Нормализовывать десятичную точку все-таки удобнее в BCD.
Вы точно не путаете понятия «поддерживается аппаратное умножение/деление» и «умножение/деление выполняется за 1 такт»?
А можно пруф?
Или хотя бы просто бенчмарк, который 2 случайных числа делит быстрее чем за наносекунду (такт сильно меньше)
По ссылке выше просто информация о медленности BCD, что логично. Поэтому никто в здравом уме в BCD мантиссы и не хранит.
Я правильно понимаю, что описано вот это, просто по-русски и другими словами?
https://en.m.wikipedia.org/wiki/Decimal_floating_point
Вычисления в decimal floating point действительно более «привычные» для человека, хотя остаётся проблема с округлением (10^64 + 10^-64 — 10^64 == 0). Основная проблема с ними — производительность, любое сложение/вычитание с разными экспонентами требует деления на степень десятки, что на порядок медленнее обычного сложения.