Интересная тема для многих: что будет нового в MetaTrader 4 и MQL4 - большие изменения на подходе - страница 49

[Avals]

hrenfx:

Не похоже. Когда мне реально надо - делаю.

Это очень плохо, если ваши возможности ограничивают какие-то разработчики стороннего софта. 

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

[Avals]

hrenfx:

Нельзя.

бред от чела вскормлённого кухней))

[hrenfx]

Avals:
Нефиг фигнёй маяться, дальше пиарасть кухню ;)

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

P.S. Для биржевиков есть ликбез, где они могут восполнить свои познания о реалиях рынка FOREX и различных отличительных чертах его от привычных им бирж. Расширяйте кругозор!

[Avals]

hrenfx:
Пиджак, не надо марать здесь свой облик среди "нубов и пиарастов" по вашей классификации. Идите в свой QQ.

здесь народ в основном не нубы, а пиараст дц ты один)

[Vladimir Gomonov]

C форматом хранимой истории (MqlRates) MetaQuotes, конечно, перемудрили (недомудрили).  Это можно понять.  Когда формат разрабатывался на рынке форекс преобладали фиксированные спреды, рыночные (плавающие) были ещё экзотикой.  Хотя было ясно, что даже фиксированные спреды по факту плавают, так как ДЦ их фиксированность "не гарантируют в моменты выхода новостей и быстрых изменений на рынке" (кавычки изображают здесь цитирование из типичной оферты практически любого ДЦ того периода).

Однако времена изменились, и мы имеем то, что имеем - спреды плавают на каждом тике.  И это нормально.  ... Только в исторических котировках это не отражено.  К сожалению.

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

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

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

Далее рассуждения о том, каким бы мог быть "полный" формат.  Я условно назвал его "Mql_6_Rates", чтоб было понятно что он в настоящее время не поддерживается. 

Ниже приводятся два варианта.  Первый  это упакованная структура (для диска).  Без сжатия спец-алгоритмами. Её ещё можно ужать в разы (2-3, предположительно) для снижения траффика при передаче.  Сжатый формат здесь не обсуждается.

struct Mql_6_PackedRates  
  {
   time_t time;            // время начала периода  4 байта  // восьмибайтный time64_t неактуален до 2038 года
   float    average_price; // средняя цена бара грубо (на три значащих цифры меньше точности _digits) 4 байта
   float    d_open;        // поправка к цене открытия 4 байта
   float    d_high;        // поправка к наивысшей цене за период 4 байта
   float    d_low;         // поправка к наименьшей цене за период 4 байта
   float    d_close;       // поправка к цене закрытия 4 байта
   ushort   spread;        // средний спред 2 байта
   char     d_open_spread; // поправка к спреду открытия 1 байт
   char     d_high_spread; // поправка к спреду high 1 байт
   char     d_low_spread;  // поправка к спреду low 1 байт
   char     d_close_spread;// поправка к спреду close 1 байт
   uint     tick_volume;   // тиковый объем 4 байт
   uint     real_volume;   // биржевой объем  4 байт
   double   OpenBid() {return (average_price+d_open); } // функции на лету вычисляющие точные значения
   double   OpenAsk() {return (average_price+d_open+OpenSpread()); }
   double   HighBid() {return (average_price+d_high); }
   и т.д...... // функции на лету вычисляющие точные значения
   ...
   ...
   double OpenSpread() { return ((spread+d_open_spread) * _digits); }
   ...
   и т.п ......
   Mql_6_Rates UnpackRates() { Mql_6_Rates Rates; ..../*заполняем*/.....  return (Rates);}
  };
// Итого у меня получилось 38 байт, всё правильно? Вся информация об 4 точках bid-ask упакована без искажений

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

Распакованная история (для доступа из MQL) могла бы быть, скажем такой:

struct Mql_6_Rates
  {
   datetime time;         // время начала периода     8 байт
   double   open_bid;     // цена открытия             8 байт
   double   open_ask;     // цена открытия             8 байт
   double   high_bid;     // наивысшая цена за период  8 байт
   double   high_ask;     // наивысшая цена за период  8 байт
   double   low_bid;      // наименьшая цена за период 8 байт
   double   low_ask;      // наименьшая цена за период 8 байт
   double   close_bid;    // цена закрытия           8 байт   
   double   close_ask;    // цена закрытия           8 байт   
   long     tick_volume;  // тиковый объем           8 байт  
   long     real_volume;  // биржевой объем            8 байт
  };

//итого = 88 байт

Это побольше чем сейчас, однако спред вычислим во всех зафиксированных точках бара. Т.е., если уж писать информацию в минутных барах по традиционной схеме {Open+High+Low+Close}, то уж "по полной программе".

По мне так эта информация избыточна, причём склонная создавать максимум иллюзий в точке Open.  Моменты открытия баров у разных символов не совпадают, в то время как точно в момент начала минуты (астрономического) цены бид-аск на символах в точности соответствуют последним прокотированным бидам-аскам, т.е. ценам закрытия.  Поэтому наиболее пригодный для тестирования формат минуток (наиболее здоровый компромисс между традицией и здравым смыслом) мог бы быть таким:

struct Mql_6_Rates
  {
   datetime time;         // время начала периода     8 байт
   double   high_bid;     // наивысшая цена за период  8 байт
   double   high_ask;     // наивысшая цена за период  8 байт
   double   low_bid;      // наименьшая цена за период 8 байт
   double   low_ask;      // наименьшая цена за период 8 байт
   double   close_bid;    // цена закрытия           8 байт   
   double   close_ask;    // цена закрытия           8 байт   
   long     tick_volume;  // тиковый объем           8 байт  
   long     real_volume;  // биржевой объем            8 байт
  };

//итого = 72 байта

//  Соответствующяя экономия в упаковнном дисковом формате составила бы ещё 7 байт, т.е. SizeOf(Mql_6_PackedRates) сократился бы до 31 байта.

Для экологичного (наиболее разумного) тестировании "по ценам открытия", должно браться астрономическое время старта минутки, т.е. цены Close предыдущего бара. В этом случае была бы достигнута точная мультивалютная синхронность цен. Эта синхронность жизненно важна для отладки мультивалютных советников торгующих рыночными ордерами.  Для торговли лимитными и стоповыми ордерами жизненно важна информация об экстремумах на каждом баре.  Она также полностью представлена в обсуждаемом формате.

--

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

[Avals]

MetaDriver:

При экологичного (наиболее разумного) тестировании "по ценам открытия", должно браться астрономическое время старта минутки, т.е. цены Close предыдущего бара.

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

p.s. если нужна экономия в трафике, то можно хранить не абсолютные значения цены, а смещения, для которых double очень много 

[hrenfx]

MetaDriver:

C форматом хранимой истории (MqlRates) MetaQuotes, конечно, перемудрили (недомудрили).  Это можно понять.  Когда формат разрабатывался на рынке форекс преобладали фиксированные спреды, рыночные (плавающие) были ещё экзотикой.  Хотя было ясно, что даже фиксированные спреды по факту плавают, так как ДЦ их фиксированность "не гарантируют в моменты выхода новостей и быстрых изменений на рынке" (кавычки изображают здесь цитирование из типичной оферты практически любого ДЦ того периода).

MT5 изначально позиционировался, как биржевой терминал. А на биржах ECN-законы ценообразования ОЧЕНЬ давно. Т.е. оправдание недоработки несостоятельно. Ну не было (и нет) в их команде сильного алготрейдера, к которому можно было прислушаться. Видимо, рулит только "количество лет успешных разработок платформ", чем здравая логика.

[Vladimir Gomonov]

hrenfx:
MT5 изначально позиционировался, как биржевой терминал. А на биржах ECN-законы ценообразования ОЧЕНЬ давно. Т.е. оправдание недоработки несостоятельно. Ну не было (и нет) в их команде сильного алготрейдера, к которому можно было прислушаться. Видимо, рулит только "количество лет успешных разработок платформ", чем здравая логика.

Я не пытался оправдывать.  Чтоб оправдывать, нужно сначала обвинить.  А мне как-то не до этого.... :)

[hrenfx]

 Тогда это снисхождение (остерегаться такого надо - хуже голой критики):

MetaDriver:

C форматом хранимой истории (MqlRates) MetaQuotes, конечно, перемудрили (недомудрили).  Это можно понять.  Когда формат разрабатывался на рынке форекс преобладали фиксированные спреды, рыночные (плавающие) были ещё экзотикой.  Хотя было ясно, что даже фиксированные спреды по факту плавают, так как ДЦ их фиксированность "не гарантируют в моменты выхода новостей и быстрых изменений на рынке" (кавычки изображают здесь цитирование из типичной оферты практически любого ДЦ того периода).

[Vladimir Gomonov]

Avals:

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

Есть такая буква. Однако геп (разрывный скачок котировки) может случиться в любой момент, а не только в начале бара.  Таки любой "прореженный" формат не без греха,  по определению.  Полный фид только в тиках.  А в истории стакана мог бы быть ещё полнее.  Я тут пытаюсь для себя минутный формат состряпать, пока нашёл такой компромисс.  Наверно оставлю как описал выше (без Open. только {Hi-Lo-Close}), понимаю все недостатки, это только одна из версий моего кодирования для своего тестера.  Предусматривается также тестирование по сырым тикам, или по искусственно прореженным любыми методами (с сохранением тикового формата {бид-аск-тайм}).