Почему double, а не decimal?

Избежать лишней конвертации при интеграции с другими системами.

В итоге, после 3-ем месяцев осмысления, я понял - переводу на decimal быть. Сейчас это сделано в отдельной ветке S#, и появиться скорее всего, в 3.1.

[smile] Замечательно-все будет очень точно)))

А ведь ни цены, ни объём не могут быть отрицательными.
Почему бы не использовать для цен тот же самый Decimal, а для объёмов ulong?

Потому что не CLS compliant.

А зачем ulong?! =) Я думаю, что даже у американцев не бывает таких сделок, чтобы они в int не поместились =) Аккумуляторы вы можете использовать такие, какие посчитаете нужным.


Зачем?! =) О какой точности идёт речь?! Точность double 15 знаков, где можно использовать бОльшую точность? Пока вы складываете и умножаете, разницы между double и decimal не будет. Сбер в пятницу на ММВБ наторговался на 24 876 860 765, это 11 знаков. То есть, чтобы добраться до ошибки, вам надо будет суммировать данные за 2000 дней. Если вы при этом перейдёте на decimal, вы получите ещё один порядок. С точки зрения обывателя это много, относительно исследуемых цифр мало -- когда у вас уже использовано 14 порядков, лишний порядок ничего не даст.

Точность у decimal выше, а ёмкость целой части такая же =) Сказки про использование decimal как решение под точные расчёты для детского сада. Потому что если бездумно делить, ошибка будет огромная и с decimal. Использовать decimal обычно неразумно -- он медленнее, больше ест памяти и не даёт ничего, кроме дополнительного порядка или двух ёмкости. Дополнительная ёмкость имеет смысл для агрегирования, ну так и используйте decimal в агрегировании за безумные интервалы. Хотя я бы в этой ситуации всё равно использовал double под промежуточные расчёты с агрегированием в ulong (20 знаков).

Мне нравиться вот этот пост http://www.rsdn.ru/forum/cpp/2640596.1.aspx Скажем, если бы я писал графическое приложение, где бы вычислял координаты - да тут точность не так важна. В случае с торговым приложение - очень важно чтобы цена были точной. Как минимум, чтобы не получить ошибку при регистрации заявок. Поэтому все всегда приходится вызывать ShrinkPrice чтобы гарантировать правильность подачи заявок.

С чем я сам столкнулся. 1 - когда я восстанавливаю стаканы из файла. Там я как раз умножаю на минимальный шаг + сдвиг от предыдущей котировкки. В итоге цена котировки 100.99999 вместо 101. 2 - когда я группирую стакан по ценовым уровня. Так же приходится округлять каждую строчку.



Если цена вычисляется через математически формулы, то ей верить без округления нельзя. В итоге ShrinkPrice кушает как раз тот прирост, что дает double перед decimal. И еще чуть больше. Получается обратная ситуация - decimal быстрее перед double, потому что первый не нужно округлять.

И да, при современных-то компьютерам. У меня весь рынок можно уместить виртуально на персональный ПС. А вот заявки все равно скользят.

Если Вы не знали, то decimal создавался именно для финансовой математики. Он не нужен скажем для расчетов в играх (по хорошему там и float хватит) и дело тут в том, что у decimal и double разное представление. У decimal фиксированная целая и дробная часть. А вот с double проблема в том что фактически оно мало какие целые числа может представить( грубо говоря будет не целое число, а 0.999999) со всеми отсюда вытекающими последствиями.

Если вы не знаете, как работает двоичное представление десятичных чисел на компьютере, советую поинтересоваться =) Пока точности double хватает, разницы с decimal нет. По ссылке Мхаила рассматриваются числа 1е-20 (разницы с 1е20 нет, к слову) и эти числа в decimal тоже не поместятся. Где на бирже такие числа? ;) Точность максимум 4-5 знаков у акций Эффективных Менеджеров ВТБ, а с учётом размера лота эти 4-5 знаков превращаются в обычные 1-2 знака.

decimal нужен там, где у вас большая целая часть и большая дробная. Попробуйте привести пример, где оно надо. Уверен, что decimal вам в этом случае не поможет.

А что, с decimal что-то меняется? ;) Два лишних знака на 15 знаках не дают ничего =)
Про графическое приложение пример мимо цели ;) Я хоть и не писал графических приложений, но поверхностно в курсе про математику, там используемую. В MS Paint, без сомнений, хватит и short, а вот когда вам надо хранить освещённость точки от нуля до 50 знаков, decimal не поможет =)

Про пост на RSDN. Человек по вашей ссылке возмущается тому же, чему возмущаюсь я. Там кто-то написал, что double сравнивать нельзя, вы пишете, что decimal вам даст большую точность.


Это в отладчике так показывается? ;) Попробуйте вывести на консоль то, что в отладчике показывается в виде 100.99999.
Не хотите разбираться с представлением чисел на компьютере, просто попробуйте. У вас число в примере четыре знака, представляя его в виде double или decimal, результат не изменится. Такие числа можно хоть в float хранить, с семью знаками, ничего не изменится. Просто смысла нет -- рантайм может его запросто хранить в 64 битах, хоть он и 32 бита, и процессор его наверняка будет считать в 64 битах. Если я неправ, покажите код или псевдокод, который приводит к 100.99999 в double и не приводит к тому же в decimal.


Не поверите -- с decimal то же самое будет =) Его точность нужна там, где большая целая часть и большая дробная. То есть, число представляется в виде 25 знаков суммарно, например. 14 на целую, 11 на дробную. Да, такое число в виде double не представить, но где у вас такие числа? Если заниматься бездумной арифметикой, decimal не спасёт.


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