Потеря тиковых данных на срочном рынке Московской биржи. - страница 3
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
OnTick() правильно делает, что без буфера - если подумать, то какой смысл в расчетах, которые всё сильней будут отставать от рынка!?
Если расчеты быстрые то всегда можно запросить информацию по тикам и все пересчитать.
Насчет тестов, кажется задержка для этого и придумана, что б воспроизвести опасность фризов в получении и отправке данных.
Советник может обработать все тики, только для этого ему нужно не только проверять последний тик в обработчике события OnTick, а запрашивать некоторый участок прошедшей истории.
См. вот эту ветку, там описание как это делается, в конце решения для обхода некоторых нюансов.
https://www.mql5.com/ru/forum/317990
Но даже если каждый раз запрашивать историю тиков с помощью функции CopyTicksRange(), получается разное поведение одного и того же кода в бэктестере и реальных торгах, т.к. событие OnTick() вызывается каждый раз в бэктестере, а в реальных торгах нет, поэтому есть опасность, что бэктест даже близко не будет соответствовать реальному рынку.
Вообще было бы здорово кроме трансляции признака агрессора (флага покупки/продажи) в тиковой истории иметь признак окончания транзакции - когда один большой ордер поражает несколько сделок, иначе со стороны клиента это выглядит как разные трейды, а на самом деле это одна атомарная операция.
OnTick() правильно делает, что без буфера - если подумать, то какой смысл в расчетах, которые всё сильней будут отставать от рынка!?
Если расчеты быстрые то всегда можно запросить информацию по тикам и все пересчитать.
Насчет тестов, кажется задержка для этого и придумана, что б воспроизвести опасность фризов в получении и отправке данных.
По первому пункту вы немного не правы, если код грамотно написан, все работает со скоростью света, и не блокирует выполнение программы, бэктест выполняется молниеносно, хотя как я уже писал выше, вызывает OnTick() каждый раз. Хотелось бы контролировать ситуацию возможно было бы выставлять какую-то глобальную переменную, чтобы включить буферизацию. И опять же OnBookEvent() буферезация реализована без проблем;
Запрос информации - это как раз ненужные накладные расходы времени при выполнении кода.
Насчет тестов - см. мой комментарий выше.
А как Вы хотите торговать на ФОРТС?
Одним инструментом, парный трейдинг, календарный спрэд или еще как-то?
По первому пункту вы немного не правы, если код грамотно написан, все работает со скоростью света, и не блокирует выполнение программы, бэктест выполняется молниеносно, хотя как я уже писал выше, вызывает OnTick() каждый раз. Хотелось бы контролировать ситуацию возможно было бы выставлять какую-то глобальную переменную, чтобы включить буферизацию. И опять же OnBookEvent() буферезация реализована без проблем;
Запрос информации - это как раз ненужные накладные расходы времени при выполнении кода.
Насчет тестов - см. мой комментарий выше.
Вы не объективны в своих суждениях. Во первых надо понимать, что MT5 используют в большинстве не дипломированные программисты, а энтузиасты трейдеры и в 99% случаев код написан не оптимально. Кроме того, большая часть советников использует в коде информацию от индикаторов, и их число может быть значительным, а индикаторам часто так же требуется время на расчет. И, я вот занимаюсь машинным обучением, у меня генерируется более 500 предикторов, а код только тела советника, без классов, более 36 000 строк и если торговать фьючерсом Si, то велик шанс к концу клиринга опоздать на пару минут.
Поэтому такие глобальные предложения нельзя рассматривать субъективно, ведь суть исполнения в OnTick() - как можно меньше во времени отставать от реальных событий, а не в последовательных и кропотливых расчетах.
Вообще было бы здорово кроме трансляции признака агрессора (флага покупки/продажи) в тиковой истории иметь признак окончания транзакции - когда один большой ордер поражает несколько сделок, иначе со стороны клиента это выглядит как разные трейды, а на самом деле это одна атомарная операция.
Этот признак - время прихода тика в миллисекундах. У тиков одной пачки одинаковое направление и время.
Вы не объективны в своих суждениях. Во первых надо понимать, что MT5 используют в большинстве не дипломированные программисты, а энтузиасты трейдеры и в 99% случаев код написан не оптимально. Кроме того, большая часть советников использует в коде информацию от индикаторов, и их число может быть значительным, а индикаторам часто так же требуется время на расчет. И, я вот занимаюсь машинным обучением, у меня генерируется более 500 предикторов, а код только тела советника, без классов, более 36 000 строк и если торговать фьючерсом Si, то велик шанс к концу клиринга опоздать на пару минут.
Поэтому такие глобальные предложения нельзя рассматривать субъективно, ведь суть исполнения в OnTick() - как можно меньше во времени отставать от реальных событий, а не в последовательных и кропотливых расчетах.
Не буду вступать с Вами в полемику по данному вопросу, да наверное у разной аудитории разные цели и задачи и в почтении склоняю шляпу перед Вашими 500 предикаторами. Я просто хотел обратить внимание разработчиков, что поведение одного и того же кода в бэктестрее и реальных торгах коде отличается, что по моему скромному мнению не есть хорошо.
Этот признак - время прихода тика в миллисекундах. У тиков одной пачки одинаковое направление и время.
Справедливое замечание, но вы можете понять, что текущая транзакция окончилась, только если уже пришел следующий тик и вы сравнили их timestamp. Т.е. Вам нужно ждать следущий тик и возможно этот тик тоже часть уже другой транзакции. Иначе получается что вы запускаете торговую логику в середине атомарной транзакции, бэктестер эмулирует исполнение вашего ордера по ценам не имеющего никого отношения к реальности. Так что получается, что OnTick() логично чтобы вызывался по окончании транзакции. Мне кажется это FX - наследие, т.к. MT5 изначально под него разрабатывался, а микроструктура у LOB/Биржевого рынка и FX все-таки различна, от этого все вышеперечисленные проблемы и вопросы.
P.S. Хотелось чтобы уже кто-то из разработчиков MetaQuotes уже вернулся с Лимассольского пляжа и уже прокомментировал свое видение ситуации :)
А как Вы хотите торговать на ФОРТС?
Одним инструментом, парный трейдинг, календарный спрэд или еще как-то?
Немножко интимный вопрос конечно, но хочу все из вышеперечисленного Вами списка :)
Я просто хотел обратить внимание разработчиков, что поведение одного и того же кода в бэктестрее и реальных торгах коде отличается, что по моему скромному мнению не есть хорошо.
Конечно, посыл верный, что б различий было как можно меньше.
Однако, пропуски зависят в первую очередь от железа - насколько быстро оно справляется с кодом, а значит тут нужен индивидуальный подход и всё равно условные значения, ведь даже замерив производительность железа, к примеру 100 тиков в секунду, никто не гарантирует, что компьютер не будет при торговле под нагрузкой или фризом и опять произойдет в связи с этим расхождение и пропуск тиков.
Получается, что для создания реальных условий Вам нужно прореживать тики, убирая те, которые Ваша машина не успевает обработать, и делать из оставшихся пользовательский символ и уже на нем тестироваться.