Float для хранения цен достаточен?

 
Сталкивался ли кто-нибудь с проблемой потери точности при хранении цен в типе float ? Золото, например, в цене 1266,357 , уже занимает максимальные 7 знаков :( ... Охота уменьшить ширину хранения в файле, а морочиться с относительными приращениями (цены) не охота :)
 

Работайте с double, используйте 64 битные версии терминала и не будет проблем.

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

Достаточно было экспортом сравнить ценовые ряды Метастока и любых других программ типа TradeStation/MetaTrader, работающих на double, чтобы увидеть существенную и важную разницу.

 

Спасибо! Я тоже уже к этому склонился...  А для объемов uchar хватит? 

 
Не хватит.
 
Renat:

Работайте с double, используйте 64 битные версии терминала и не будет проблем.

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

Достаточно было экспортом сравнить ценовые ряды Метастока и любых других программ типа TradeStation/MetaTrader, работающих на double, чтобы увидеть существенную и важную разницу.

Хм... У меня один знакомый также сталкивался с данным минусом Метастока. А я ему еще не поверил...  Говорит, сильно помогало введение "банковского" округления значений (когда округление с недостатком или избытком производится в зависимости от четности предыдущей цифры). Выходит, и правда ???
 
sealdo:
Сталкивался ли кто-нибудь с проблемой потери точности при хранении цен в типе float ? Золото, например, в цене 1266,357 , уже занимает максимальные 7 знаков :( ... Охота уменьшить ширину хранения в файле, а морочиться с относительными приращениями (цены) не охота :)
Единственное серъезнейшее преимущество float перед double это двухкратное превышение производительности векторизованных операций в OpenCL (см. спецификацию в статьях). Учитывая дискретность (конечность) биржевых цен использование float не лишено смысла. Но этот вопрос нужно серьезно проработать, что бы на него можно было дать взвешенный ответ.
 
sealdo:
Сталкивался ли кто-нибудь с проблемой потери точности при хранении цен в типе float ? Золото, например, в цене 1266,357 , уже занимает максимальные 7 знаков :( ... Охота уменьшить ширину хранения в файле, а морочиться с относительными приращениями (цены) не охота :)
Если цен много и они схожие, теоретически если хранить базовое double значение а остальные как смещение от базового (даже в пунктах), можно достичь значительной степени сжатия.
 
Laryx:
Хм... У меня один знакомый также сталкивался с данным минусом Метастока. А я ему еще не поверил...  Говорит, сильно помогало введение "банковского" округления значений (когда округление с недостатком или избытком производится в зависимости от четности предыдущей цифры). Выходит, и правда ???

Правда. Я сам лично это разбирал, сравнивал и реализовывал.

Еще в 2000 году в платформе MetaQuotes был прямой экспорт в рилтайме цен и чартов в Метасток.

 
float'ы еще и медленнее считаются - FPU их недолюбливает, видимо ))
 

Получается, что при таком раскладе, в текстовом формате в файле это компактнее...

Появилась такая вот мысль (опять, наверное, велосипед изобрел :) использовать простое двухкратное сжатие текстового представления чисел и попутных знаков. Символы (0123456789.:;-) количеством в пределах 16-ти, т.е. можно уместить в 4 бита, т.е. в 1 байт можно засунуть два цифро-символа :)

 
sealdo:

... Появилась такая вот мысль (опять, наверное, велосипед изобрел :) ...

Давным-давно был такой двоично-десятичный код. Даже сейчас наверно остались для совместимости команды процессора для работы с ним ))