Организация цикла перебора ордеров - страница 4
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Ее не будет, т.к. не силен.
Сначала ТС пишется для тестера, где идеальные торговые условия. Если все хорошо, то стараются боевой вариант написать так, чтобы на реале было как можно ближе к тому, что видят в тестере. Любые другие подходы при написании ТС - это авось, а не алгоритмизация идеи.
Так вот фундаментальный вопрос, какая же боевая ситуация является наиболее близкой к тестеру? Свое мнение озвучил (и пример привел), Ваше услышал.
Тоже столкнулся с задачей максимально точного перевода торговой логики эксперта с тестирования на тиках в тестере стратегий (МТ4), на работу его же на реальном счете.
Мои рассуждения:
В тестере эксперт работает не только в идеальных торговых условиях, но, по сути, в другом режиме – в режиме реального времени, т.е. за один тик он там успевает и рассчитать ТС, и отправить ордер, и получить на него ответ, а вот при реальном использовании на торговом счете это уже не так. Получается, что мы имеем как бы два разных робота - один реального времени, другой нет. Отправляем /модифицируем ордер (даже один!) на реальный счет = пинг +время исполнения и т.д. = в лучшем случае 100-500мс, а в это время идут тики и их надо считать – а мы стоим, ждем... а потом вбухиваемся в поток в случайном порядке (куда ушла цена за это время относительно наших тиковых средних х.з. + мы наверняка пропустили несколько самых быстрых, и, как правило, самых важных тиков). Получается, что в итоге от нашей стратегии, которую мы откатали в тестере, может вообще ничего не остаться.
Поэтому, поразмышляв, я пришел к следующему:
Поэтому, поразмышляв, я пришел к следующему:
Да, такой же подход использую - своего рода внутренний идеальный тестер со своими открытыми ордерами и копировщик, который эти виртуальные ордера пытается материализовать. Много тяжелых подводных камней такая схема обходит с легкостью.
В MT5 попроще, т.к. там можно запросить тиковую историю. И по нескольким инструментам.
Речь не про время, а про логику (про время - это в другой ветке ;-) ). Ваша логика (и моя логика, т.к. я согласен со всем, включая и аналогию с авто) - в том, чтобы анализ окружения делать "одним махом и целиком", а не по частям. Обработка любых побочных эффектов откладывается до следующего захода, т.к. эти эффекты встроятся в новое торговое окружение.
Ну, если бы не было поправки на время, то обе логики (и моя, и fxsaber) были бы идентичны — все ордера были бы обработаны на каждом тике даже после нескольких ошибок.
Задача именно в том, чтобы приблизить реальность с не моментальным исполнением к идеальной модели, полученной при тестировании.
Да, такой же подход использую - своего рода внутренний идеальный тестер со своими открытыми ордерами и копировщик, который эти виртуальные ордера пытается материализовать.
Если материализовать с вашим подходом (в цикле, оставаясь на первом ордере до его успешной синхронизации с реальностью), можно нарваться на ту же проблему потери из поля зрения (или просто более поздней обработки) остальных ордеров. Но это на все ту же, якобы завершенную, тему )
Если материализовать с вашим подходом (в цикле, оставаясь на первом ордере до его успешной синхронизации с реальностью), можно нарваться на ту же проблему потери из поля зрения (или просто более поздней обработки) остальных ордеров. Но это на все ту же, якобы завершенную, тему )
Вот так и торгуем-с!
Ждем ООП-примера. И мне он видится все тем же костяком в виде цикла. От того, что сначала будет for определять, что надо поменять, а потом for по уже принятым решениям, логика не поменяется.
Конкретно для этой задачи я писать пример не буду. Но упрощенную концепцию подхода можно посмотреть в моем блоге. Там очередь вглубь не анализируется, а только проверяется на пустоту. Желающие могут усовершенствовать.
Если под логикой понимать целиком задачу "модифицировать кучу ордеров под изменившиеся цены", то она одна. Вопрос в том, что важнее при реализации: модифицировать все ордера, или модифицировать под самые последние цены? В зависимости от предпочтений логика здесь будет уже разная. Простой цикл гарантирует модификацию всех ордеров, и я за этот вариант. Как уже было сказано, ООП обеспечивает наглядность разделения задачи на блоки ответственности, и на основании этой декомпозиции "все ордера" важнее "актуальности цены". Это ясно даже исходя из того, что цены меняются постоянно, а ордера есть лишь иногда. Они важнее.
ООП обеспечивает наглядность разделения задачи на блоки ответственности, и на основании этой декомпозиции "все ордера" важнее "актуальности цены"
На основании этой декомпозиции следует только разделение. "Актуальность цены" при таком ООП достигается установкой места в очереди.
Это уже какая-то "философия" пошла. Обработка ведется по очереди ордеров, а не по потоку тиков, как предлагается в альтернативном варианте. В общем, я из этой дискуссии устраняюсь. Все доводы уже были приведены.
В общем, я из этой дискуссии устраняюсь. Все доводы уже были приведены.
Уже тенденция так завершать.
Ниже будет затронута тема, которая касается не только MT4, но и MT5 с другими платформами. Но для удобного восприятия логика будет написана на MQL4, поэтому в этой ветке.
Чаще всего костяк (мясо наращивается любое) модификации/удаления ордеров сводится к следующей логике
А теперь подход редкий, но гораздо правильнее
После отправки торгового приказа меняется торговое окружение, поэтому желательно сразу после ответа торгового сервера выполнять с нуля всю торговую логику ТС.
Зацикливание один из опаснейших приемов программирования. Чреват странными, редко проявляющимися ошибками, которые почти невозможно проанализировать.
Вместо зацикливания, нужно наоборот, стараться как можно быстрее завершить пользовательский поток. Если так хочется держать "руку на пульсе" - анализируйте OnTradeTransaction в МТ5. МТ4 вообще плохо для таких вывертов подходит, ибо простота как говориться хуже воровства.