ФорумРазделы

Bid && Ask && Spread - страница 4

Новый комментарий
hrenfx:

Честно ответить можете, какие доводы в пользу использования OHLC Bid + Spread, против OHLC Bid + OHLC Ask? Хранить 8 чисел, вместо 5-ти (формат бара и истории сложно поменять)? Это существенно скажется на объеме предоставляемой истории? Или, может, у вас просто нет истории Ask-цены? Логика тестера усложняется? Так во втором случае она даже проще - нет понятия спреда вообще. Что останавливает, честно скажите. 

Размер структуры бара - самая значимая характеристика, пропорционально влияющая на объем потребляемых ресурсов терминалом.

Перед нами всегда стоит задача экономии ресурсов, поэтому расширение в таком виде не подходит.

Документация по MQL5: Основы языка / Операции и выражения / Другие операции
Документация по MQL5: Основы языка / Операции и выражения / Другие операции
  • www.mql5.com
Основы языка / Операции и выражения / Другие операции - Документация по MQL5

Размер MqlRates:

struct MqlRates
  {
   datetime time;         // время начала периода
   double   open;         // цена открытия
   double   high;         // наивысшая цена за период
   double   low;          // наименьшая цена за период
   double   close;        // цена закрытия
   long     tick_volume;  // тиковый объем
   int      spread;       // спред
   long     real_volume;  // биржевой объем 
  };

равен (если не ошибся) 46 байтам.

Размер альтернативной структуры:

struct MqlRates
  {
   datetime time;         // время начала периода

   double   openBid;      // цена открытия Bid
   double   highBid;      // наивысшая цена за период Bid
   double   lowBid;       // наименьшая цена за период Bid
   double   closeBid      // цена закрытия Bid

   double   openAsk;      // цена открытия Ask
   double   highAsk;      // наивысшая цена за период Ask
   double   lowAsk;       // наименьшая цена за период Ask
   double   closeAsk      // цена закрытия Ask

   long     tick_volume;  // тиковый объем
   long     real_volume;  // биржевой объем 
  };

равен 76 байтам.

Т.е. речь идет об увеличении объема траффика при закачке истории и потребляемой памяти терминалом и тестером (включая агенты) в самом худшем случае на 65%. Понятно, что всего какие-то 65% не могут вас остановить. Причины явно другие.

[Удален]
hrenfx:

Если вы не верите словам оппонента, какой смысл разговаривать?

А если верить всем словам оппонента, какой смысл разговаривать? Не надо крайностей.
hrenfx:

Размер MqlRates:

равен (если не ошибся) 46 байтам.

Размер альтернативной структуры:

равен 76 байтам.

Т.е. речь идет об увеличении объема траффика при закачке истории и потребляемой памяти терминалом и тестером (включая агенты) в самом худшем случае на 65%. Понятно, что всего какие-то 65% не могут вас остановить. Причины явно другие.

У меня 48 байт получилось:

struct MqlRates
  {
   datetime time;         // время начала периода
  
   double   Base;          // базовая цена бара.  Все остальные цены отсчитываются от базы в пипсах 

   short     openBid;      // цена открытия Bid
   short     highBid;      // наивысшая цена за период Bid
   short     lowBid;       // наименьшая цена за период Bid
   short     closeBid      // цена закрытия Bid

   short     openAsk;      // цена открытия Ask
   short     highAsk;      // наивысшая цена за период Ask
   short     lowAsk;       // наименьшая цена за период Ask
   short     closeAsk      // цена закрытия Ask


   long     tick_volume;  // тиковый объем
   long     real_volume;  // биржевой объем 
  };
Кто скажет, что шорта недостаточно - пусть первым кинет в меня хотя бы один пример (всё равно с биржи или форекса).
Renat:

Размер структуры бара - самая значимая характеристика, пропорционально влияющая на объем потребляемых ресурсов терминалом.

Перед нами всегда стоит задача экономии ресурсов, поэтому расширение в таком виде не подходит.

Ренат, а были ли какие-нибудь попытки оптимизации структуры MqlRates? Например, зачем нужна double (8 байт) точность значениям OLHC, если точность сейчас ограничена максимум пятью знаками после запятой? Почему бы не хранить эти значения как нормализованные на 3 или 5 разрядов int, которые занимают в два раза меньше памяти?

Максимальное значение, которое можно записать при таком подходе - это 42949.67295.

Есть ли данные OLHC на форекс, которые выйдут за эту границу? 

Vladix:

Есть ли данные OLHC на форекс, которые выйдут за эту границу? 

а почему только форекс? платформа не только форекс символы обслуживает.
MetaDriver:

У меня 48 байт получилось:

Кто скажет, что шорта недостаточно - пусть первым кинет в меня хотя бы один пример (всё равно с биржи или форекса).
hrenfx:

Т.е. речь идет об увеличении объема траффика при закачке истории и потребляемой памяти терминалом и тестером (включая агенты) в самом худшем случае на 65%. 

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

Vladix:

Например, зачем нужна double (8 байт) точность значениям OLHC, если .....................

Вот ксати, ДА.  

   double   Base;          // базовая цена бара.  Все остальные цены отсчитываются от базы в пипсах
вполне можно заменить на
   float    Base;          // базовая цена бара.  Все остальные цены отсчитываются от базы в пипсах

и не будет НИ ОДНОГО пострадавшего.  Тогда размер волшебным образом возвращается к 46 байтам.  Здорово, правда?  :)

MetaDriver:

У меня 48 байт получилось:

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