Насущные вопросы про тиковые объёмы и цену Last под катом
ByBitCharts (https://www.mql5.com/ru/blogs/post/756894) идёт к релизу, и есть насущные вопросы:
Что правильнее считать тиковым объёмом ?
поясняю - отдельно существующих тиков НЕТ. Криптобиржи не считают такой показатель как тиковый объём. Для того чтобы всё было по возможности правильно, MqlTick::volume рассчитывается самим BaBytCharts.
Вопрос: что считать тиковым объёмом ? варианты:
- кол-во принятых тикеров. Биржи транслируют не тики, а тикеры - структура близкая к тику, но это просто оповещение. ByBit обещает (по документации, и есть сомнения) что тикеры выдаёт в реальном времени от событий, другие транслируют периодично.
- счётчик изменений цены Bid стакана.
- кол-во пунктов изменений Bid. При изменении Bid считать пункты и складывать
- кол-во сгенерированных тиков. Тики генерируются при изменении любой из цен: Bid, Ask, Last
Что указывать в цене last генерируемых тиков ?
Конечно цену, получаемую от ленты сделок. Но сделки приходят пачками. В пачке их может быть 20-30 и последних по времени может быть сразу 5 Buy и 3 Sell. Тут снова варианты:
- среднюю цену всей пачки (и объём соответсвенно). Так сумма объёмов тиков сойдётся с объемом присылаемых свечей, но цена будет усредненна
- среднюю цену последней по времени серии, то есть сделок имеющих максимальный timestamp. Цена ближе к правде, но объёмы не сойдутся и часть информации утеряна
- в последней серии, выбирать по порядку последнюю сделку и брать её цену и объём. Ближе всего к определению last - цена последней сделки. Но и информации много теряется и очерёдность сделок имеющих один timestamp сильно под вопросом.
НАДО ОПРЕДЕЛИТЬСЯ С ЭТИМИ МОМЕНТАМИ.
Принятое решение далее меняться уже не будет - для других бирж будет то-же самое, однотипно.
----
ну и вкратце про текущее : В ATcl (https://sourceforge.net/projects/mt-atcl/) добавляется поддержка ulong и long long и как задел на будущее библиотека ZMQ. Строить коммуникации с советниками станет ещё проще.
