Программирование, Путешествия, Покер

Почему для денежных расчетов нельзя использовать double?

public class doublePrecision {

    public static void main(String[] args) {

          double total = 0;

          total += 5.6;     

          total += 5.8;

          System.out.println(total);  

    }

}

Result: 11.399999999999

Algoritmik, а если округлить до двух знаков после запятой?

Цитата (Algoritmik @ 15.07.21)  

public class doublePrecision {

    public static void main(String[] args) {                       double total = 0;

          total += 5.6;     

          total += 5.8;

          System.out.println(total);  

    }

}

 

Result: 11.399999999999

Проверил на Go, тоже самое. Прикольно, я не знал, так как очень мало с флотами/даблами работал и никогда не имел дел с деньгами (видимо как и тот индус).

Algoritmik, а если округлить до двух знаков после запятой?

А если таких операций миллионы? Сотни миллионов? А если мы вычитаем? А проценты? Деривативы? Там много таких "если"...

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

double first = 9_000_000_000_000_000_000.0;
double second = 100.0;
double sum = first + second;
System.out.println(first == sum);

Можно подробнее почитать на эту тему например на stackoverflow

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

очень мало с флотами/даблами работал и никогда не имел дел с деньгами

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

Цитата (strkk @ 15.07.21)  

почему для денежных расчетов не надо использовать double

Ну это скорее стереотип, все зависит от конкретной задачи. Например, в API Interactive Brokers спокойно используется тип double везде. Но на интервью лучше отвечать конечно стандартным образом, что использовать double при работе с деньгами не следует.

Цитата (spirit83 @ 16.07.21)  

Например, в API Interactive Brokers спокойно используется тип double везде.

Использование его в апи никак не говорит о том, каким образом в потрохах IB идут вычисления.

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

double - это тип с которым умеет работать проц, любая современна апишка как правило принимает json запрос в котором нет типов как таковых, просто строка

{

"id": 1000,

"value":23.98432

}

и представлено в виде строки, если бек работает с деньгами он переложит это в тип fixed-point а не в double

Цитата (strkk @ 16.07.21)  

Использование его в апи никак не говорит о том, каким образом в потрохах IB идут вычисления.

Это конечно да.

Цитата (strkk @ 16.07.21)  

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

Нет, это необязательно. Всегда можно в интерфейс добавить кастомную структуру или тип данных, если стандартный тип не устраивает. Сам тип double хранит данные с некоторой погрешностью и если эта погрешность неприемлема вводится другой тип.

Цитата (strkk @ 16.07.21)  

но, еще раз повторюсь, это ровно никак не говорит о том, каким образом там идут вычисления или, например, на каком языке у них написан бэкенд

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

Ну и это только один из примеров. В торговых симуляторах тоже часто используют просто double и специальные техники чтобы уменьшить погрешность.

Цитата (strkk @ 15.07.21)  

Забавно, что сегодня собеседовали чувака из индийского амазона. Очень слабый кандидат, мало на что ответил, не смог обычный REST-эндпоинт написать и рассказать, почему для денежных расчетов не надо использовать double. При этом я даже не беру вещи, которые можно списать на знание именно джавы (хотя, например, чел не знал что equals и hashCode надо переопределять вместе, а это прям базовая база)

 

А тупее всего то, что на бумаге этот чел - SDE II, а на такой же уровень оценили меня после собеса в ноябре. Зачем так жить       

Ничёсе, это же вопросы для Junior lvl.

А мне интересно, был ли он в чём-то хорош? Может он дизайн расписал хорошо или процессы отлично налаживает?

Цитата (spirit83 @ 16.07.21)  

Сам тип double хранит данные с некоторой погрешностью

Это как тип может хранить данные с погрешностью?) Допустим у нас работа с курсами валют, точность до 4 знака после запятой, правила округления определены цб, используя дабл мы теряем значение в крайнем порядке только из-за использования неправильного типа данных, но полученный дабл мы можем переложить например в bigdecimal для java, выполнить рассчеты и так же округлить до требуемого значения, но уже без потерь в точности, за которые я подозреваю финансовую организацию поимеет регулятор и я могу представить, что дабл в вычислениях где-то  используется только из-за присущей некоторым специалистам халатности

Интересная история была связанная с double

из-за того, что

получилось вот такое:

Цитата (spirit83 @ 16.07.21)  

Ну и это только один из примеров. В торговых симуляторах тоже часто используют просто double и специальные техники чтобы уменьшить погрешность.

это если торговый симулятор написан через жопу, и их начинал писать индус из собеса автора, все грамотные симуляторы для работы с деньгами используют fixed point

Интересная статья на хабре про собеседования – https://habr.com/ru/post/534902/

Больше всего меня удивил момент, где они дают программисту на тестовом периоде делать задания, которые уже сделаны :thinking:

Цитата (Levind @ 16.07.21)  

Это как тип может хранить данные с погрешностью?)

Многие десятичные дроби не имеют точного представляени в типе double, а значит эти дроби хранятся с некоторой погрешностью

Цитата (Levind @ 16.07.21)  

Допустим у нас работа с курсами валют, точность до 4 знака после запятой, правила округления определены цб, используя дабл мы теряем значение в крайнем порядке только из-за использования неправильного типа данных, но полученный дабл мы можем переложить например в bigdecimal для java

Не понял, что ты тут хочешь, дабл округлить и переложить bigdecimal ? Ну можно как угодно извращаться в принципе. Но проще наверное просто использовать bigdecimal  или double, если его точность устраивает

Цитата (valeg @ 16.07.21)  

это если торговый симулятор написан через жопу, и их начинал писать индус из собеса автора, все грамотные симуляторы для работы с деньгами используют fixed point

Сильное заявление. Был у меня проект торговый симулятор, написанный не индусами, и везде там использовался тип double и не было никакой необходимости использовать fixed point. А вместе с ним еще был торговый бот и тоже везде использовался тип double, и писали его опять же не индусы.

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

Цитата (valeg @ 16.07.21)  

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

Да нет, ошибка не критическая, просто если можно посчитать точнее, почему это не сделать. Кроме того есть случаи, когда просто технически невозможно посчитать точно. Например, нам нужно посчитать среднее арифметическое двух чисел, а эти числа (в любом типе) находятся рядом друг с другом. Для простоты возьмем целый тип, какое среднее арифметическое будет у 2 и 3, 2.5, но оно уже не может быть представлено в целом типе. И так же будет с любым другим типом ограниченной точности. То есть тут никакой тип не поможет.

В целом типе не представишь

Например в bitshares все деньги хранятся в UINT64, и оговорено, что там лежит в микрорублях значение, точность до микрорублей, и все умножения, деления делаются по детерменированному алгоритму. Это когда изначально проектируется система как надо. В биткоине вроде тоже в сатоши все летает, но это не точно