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