Организация цикла перебора ордеров - страница 2
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Потому что цена будет двигаться, и на каждом новом вызове ОнТик будет выполняться условие для новой модификации все того же, первого в списке, ордера. Особенно, если модификация будет длиться 5 секунд ;)
Опять же затрагивается вопрос актуальности. Один ордер будет всегда в актуальном состоянии. Остальные - по возможности. Ваш же вариант - все ордера не в актуальном состоянии.
Такой "костяк" сломает логику советника, работающего с более чем одним ордером.
Какой в нем смысл, если он не даст ни каких преимуществ для систем с одним ордером и испортит остальные?
Рад бы понять, что имеете в виду, но не получается. Не вижу проблемы в принципе "если прошло время ожидания, обнови торговое окружение".
Сортировка по объему и/или отдаленности от цены перед работой с ордерами — правильное решение. Но не нужно подразумевать, что все, кто скопирует код с форума, будут ее реализовывать.
В этом смысле мой код безопаснее.
Ну не для новичков же было написано. Мы с Вами очень хорошо это здесь обсуждаем - без воды.
Опять же затрагивается вопрос актуальности. Один ордер будет всегда в актуальном состоянии. Остальные - по возможности. Ваш же вариант - все ордера не в актуальном состоянии.
Актуальном — на сколько?
Рад бы понять, что имеете в виду, но не получается. Не вижу проблемы в принципе "если прошло время ожидания, обнови торговое окружение".
Ваш алгоритм зациклен на первом в списке ордере, вот и все.
В некоторых ситуациях это может быть губительным для системы (я встретился с этим на практике).
Актуальном — на сколько?
В моем варианте оба СЛ были бы модифицированы на 1.2375 или, в худшем случае, на 1.2374. Итог: +30 пунктов по обоим ордерам.
На каждом шаге в Вашем примере ТС должна знать, где должны быть ее ордера без какого-либо торгового приказа. Т.е. ТС вообще никак не может быть привязана к тому, где там сейчас стоят ордера. Она занимается только вычислением, где они должны стоять, а также синхронизацией торгового окружения с тем, что насчитала, через торговые приказы.
В Вашем же примере результат ТС зависит от того, пришел ли OnTick на High-цене или нет. А правильной ТС должно быть ровно до этого. Она видит, что такая цена была (даже если OnTick с ней был пропущен), а значит соответствующим образом должны размещаться ее СЛ. И синхронизация сделает свое дело на 100%.
И я не понимаю, почему Вы все время говорите, что второй стоит на месте. Даже без логики синхронизации он все равно будет модифицироваться так же, как в Вашем варианте. Вызывается же OnTick не на событие NewTick, а как обычная внутренняя функция.
На каждом шаге в Вашем примере ТС должна знать, где должны быть ее ордера без какого-либо торгового приказа. Т.е. ТС вообще никак не может быть привязана к тому, где там сейчас стоят ордера. Она занимается только вычислением, где они должны стоять, а также синхронизацией торгового окружения с тем, что насчитала, через торговые приказы.
Так и есть, она знает. Но синхронизировать не успевает — пока проходит одна модификация, цена уходит дальше, и новое просчитанное состояние говорит ей модифицировать опять первый ордер. И так все время.
В Вашем же примере результат ТС зависит от того, пришел ли OnTick на High-цене или нет. А правильной ТС должно быть ровно до этого. Она видит, что такая цена была (даже если OnTick с ней был пропущен), а значит соответствующим образом должны размещаться ее СЛ. И синхронизация сделает свое дело на 100%.
Не зависит (в примере расчетов уровня СЛ не было).
А синхронизация дело не сделает, т.к. не успеет (см. выше).
И я не понимаю, почему Вы все время говорите, что второй стоит на месте. Даже без логики синхронизации он все равно будет модифицироваться так же, как в Вашем варианте. Вызывается же OnTick не на событие NewTick, а как обычная внутренняя функция.
Как обычная, я это понял.
Но, пока шла модификация, цена уже изменилась, и принудительный вызов ОнТик уже работает с новой ценой, а второй ордер так и остается на начальном уровне.
Ошибки нет. Возможно, слишком специфическая для вас (но, повторюсь, вполне реальная, из жизни) ситуация.
Так и есть, она знает. Но синхронизировать не успевает — пока проходит одна модификация, цена уходит дальше, и новое просчитанное состояние говорит ей модифицировать опять первый ордер. И так все время.
Придуманный Вами пример только доп. убытка не приносит при такой логике. Теперь с меня пример.
Пусть мы трейлим BuyLimit-ы за движением вверх, чтобы открыться на нужном откате. Почти Lucky-ТС. Если мы будем тащить гору лимитников каждый раз, мы не поймаем откат при Вашем варианте.
Ну странно отдавать торговые приказы на основе устаревшего торгового окружения. Но Вы упорно (как и я) отстаиваете иную точку зрения.
Ну странно отдавать торговые приказы на основе устаревшего торгового окружения. Но Вы упорно (как и я) отстаиваете иную точку зрения.
Приходится выбирать из двух зол меньшее.
Пример с лимитом, тянущимся за ценой, конечно, лучше реализовывать в варианте "1 советник = 1 ордер в каждом направлении".
Но в общем случае правильнее держать под контролем все свои ордера.
Но в общем случае правильнее держать под контролем все свои ордера.
Т.е. Вы не согласны с требованием для ТС работать только с актуальным торговым окружением.
Т.е. Вы не согласны с требованием для ТС работать только с актуальным торговым окружением.
Если для этого придется пожертвовать контролем за всеми ордерами ТС — безусловно.
Представьте: у вас авто-парк из 4 грузовиков. Каждый из них везет ценный груз из точки А в точку Б. Вам нужно проконтролировать маршрут.
Что вы предпочтете: иметь связь каждую минуту - с одним из них, или раз в 2 минуты - со всеми?
Во втором случае задержка будет чуть больше, и, возможно, всем четырем придется сделать небольшой крюк, если вы их не успеете направить. Но в целом для бизнеса это будет выгоднее, чем провести один грузовик и потерять три остальных.
Если для этого придется пожертвовать контролем за всеми ордерами ТС — безусловно.
Представьте: у вас авто-парк из 4 грузовиков. Каждый из них везет ценный груз из точки А в точку Б. Вам нужно проконтролировать маршрут.
Что вы предпочтете: иметь связь каждую минуту - с одним из них, или раз в 2 минуты - со всеми?
Во втором случае задержка будет чуть больше, и, возможно, всем четырем придется сделать небольшой крюк, если вы их не успеете направить. Но в целом для бизнеса это будет выгоднее, чем провести один грузовик и потерять три остальных.
+1.
Возможно новая идея не возникла бы при ООП подходе, когда аналог цикла с перебором ордеров скрыт в какой-то сущности типа менеджера, который вместо непосредственного вызова OrderModify формирует команду на модификацию (со всеми параметрами) и помещает её в очередь, которая затем обрабатывается. Суть в том, чтобы разделить ответственность (которая в приведенном коде запихнута в единый цикл) между неким объектом анализа окружения и объектом выполнения действий на основе анализа.
Возможно данная идея не возникла бы при ООП подходе, когда аналог цикла с перебором ордеров скрыт в какой-то сущности типа менеджера, который вместо непосредственного вызова OrderModify формирует команду на модификацию (со всеми параметрами) и помещает её в очередь, которая затем обрабатывается. Суть в том, чтобы разделить ответственность (которая в приведенном коде запихнута в единый цикл) между неким объектом анализа окружения и объектом выполнения действий на основе анализа.
Избежать такой ситуации получилось бы только с помощью асинхронных приказов.
Иначе все равно будет цикл по списку команд, которые нужно выполнить, а это, по сути, и есть цикл по ордерам.
Только в ситуации с очередью еще нужно было бы предусмотреть вытеснение более старого неисполненного приказа, относящегося к ордеру, более новым. Иначе очередь могла бы переполниться, а приказы из нее отправляться - устаревшие.