Мультитерминальный ММ для MT4 - страница 3
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
А что это тогда, если не мартингейл?
Или просто другая система увеличения лота (не удвоение)?
Такой разброс в объемах - это попытка перекрыть предыдущие неудачные входы, другого объяснения нет.
Да,. я экспериментирую с разными моделями увеличения объема позиции, использую сейчас в торговле последовательность Фибоначчи.
Философия открытия у меня не сводится к примитивному перекрытию, но не думаю, что тут стоит это обсуждать, а то зафлудим ;)
Прибыль считали?
Да.
Пропуск в начале пары сигналов я рассматриваю, как решение задачи, но предварительные расчеты показали существенную потерю прибыли.
Вот в общем то по пункту 1 нужны идеи, как организовать последовательную синхронизацию - после каждой операции ждать особый флаг о том, что этап обработки завершен?
Второй пункт так же актуален, если был сбой, то с какого пункта требуется начать протокол взаимодействия, дабы избежать ошибочных действий?
Контроль протокола может сделать через глобальные переменные терминала? При сбои они сохраняются?
Вы хотите с наскоку состряпать сложный алгоритм. Не получится )
Моя идея заключалась в следующем:
1. Торговый советник.
Анализирует котировки, торгует виртуально (полностью независимо от внешнего мира).
Данные о текущих позициях и ордерах хранит в файле с уникальным идентификатором в названии, в общей папке терминалов. Например, так:
EURUSD;+0.4
GBPUSD;-0.7
Что означает: должны быть открытыми 2 позиции, бай 0.4 по евродоллару и селл 0.7 по фунту.
2. Советник-исполнитель.
Сообщает о своей активности, обновляет информацию о счете (баланс, список сделок, свободную маржу, торговые условия).
Данные записывает в файл с номером счета в названии, в общую папку терминала.
Выполняет синхронизацию состояния счета с файлом приказов, предназначенным для этого счета (записывается менеджером). Например, если в файле указано, что на этом счете должна быть позиция бай EURUSD 0.2 лота, а есть селл 0.1 лот, то он закрывает селл и открывает бай.
3. Советник-менеджер.
Собирает информацию от всех виртуально торгующих советников (перебирает файлы из общей папки).
Собирает информацию о всех доступных терминалах, состоянии счетов и открытых на них позициях (из той же общей папки).
Анализирует все данные и раздает приказы на синхронизацию во все треминалы (говорит, где, чего и сколько должно быть открыто).
Это на коленке, за 5 минут. В процессе реализации появится еще ряд вопросов.
Более глубоко и подробно продумывать алгоритм за вас ради интереса не хочу )
Но если будут конкретные вопросы или проблемы, готов помочь.
Извините за множественные редактирования поста.
MQ наконец-то сделали отправку сообщения на форум по Ctrl+Enter, и я иногда с перепугу отправляю неготовый текст ;)
Вы хотите с наскоку состряпать сложный алгоритм. Не получится )
Я лишь описал примерный алгоритм, без деталей. К этому алгоритму нужно сделать структуру хранения информации, и дальше останутся технические вопросы.... или просто я пока не вижу особых проблем в алгоритме, ну, кроме организации синхронизации.
Моя идея заключалась в следующем:
Ваша идея понятна, но она не дает возможности торговому (на котором ТС) советнику знать о состоянии текущих дел, а для меня это важно, так как фактически открытые ордера влияют на принятие торговых решений - нужно знать среднюю цену позиции. К тому же, мне нужен алгоритм, который сможет работать как с рыночными ордерами, так и с отложенными, в том числе производить модификацию ордеров.
Более глубоко и подробно продумывать алгоритм за вас ради интереса не хочу )
Но если будут конкретные вопросы или проблемы, готов помочь.
Спасибо.
Вопрос для меня пока открыт - как синхронизировать поэтапно работу алгоритма? Допустим у меня 50 советников, каждый из них должен получить информацию о фактически открытых ордерах и отправить менеджеру приказы, и только после получения всех приказов менеджер должен распределять их по счетам. Или не дожидаться сброса приказов от всех советников, но тогда как менеджер будет знать, что часть запросов уже исполнил, а оставшаяся часть ещё не пришла даже?
Ваша идея понятна, но она не дает возможности торговому (на котором ТС) советнику знать о состоянии текущих дел, а для меня это важно, так как фактически открытые ордера влияют на принятие торговых решений - нужно знать среднюю цену позиции. К тому же, мне нужен алгоритм, который сможет работать как с рыночными ордерами, так и с отложенными, в том числе производить модификацию ордеров.
Нет, вы не поняли мою идею.
Торговые советники не должны получать ответ, они должны торговать виртуально и полностью независимо.
Например, вместо открытия позиции, советник должен добавить в свой виртуальный список новую запись с названием инструмента, текущей ценой, лотом, и остальными параметрами.
А для проверки текущей прибыли нужно перебирать не реальные сделки, а этот виртуальный список (и считать, сколько по каждой позиции набежало прибыли с учетом текущей цены).
С отложенными ордерами (а также СЛ и ТП) - аналогично: запоминаем цену ордера, и на каждом тике проверяем, не "сработал" ли он.
Т.е. нужно сделать обертки всем Order* функциям и несколько сервисных функций для отслеживания состояний.
Я даже писал когда-то такую библиотеку, но в каком она сейчас состоянии сложно сказать, давно дело было.
Иначе вы погрязнете в постоянной синхронизации, а процесс распределения нагрузки на счета будет очень сложным.
Нет, вы не поняли мою идею.
Я понял Вашу идею, просто она не согласуется с моим виденьем проблемы. Мне важно получать реальную цену открытой позиции, а не предполагаемую - в этом загвоздка. А если ордер рыночный вообще не открылся, то прахом летит вся ТС?
Т.е. нужно сделать обертки всем Order* функциям и несколько сервисных функций для отслеживания состояний.
Полностью согласен - хочу добавить в класс по работе с ордерами алгоритм виртуализации ордеров.
Иначе вы погрязнете в постоянной синхронизации, а процесс распределения нагрузки на счета будет очень сложным.
Вот и хочется найти оптимальное решение, что б не погрязнуть, но иметь возможность получать реальную торговую информацию.
Вот и хочется найти оптимальное решение, что б не погрязнуть, но иметь возможность получать реальную торговую информацию.
Как вам поможет реальная цена открытия?
Проскальзывание учитывать нужно, но для этого не обязательно наблюдать за каждой сделкой - достаточно собрать статистику и закладывать какое-то среднее значение в планируемую прибыль.
И опять таки... Проскальзывание - на центовых счетах? Проскольз на один пункт одной сделки лотом 50 нивелирует кучу проскользов от мелких сделок. Вот за ним и нужно следить.
А если ордер рыночный вообще не открылся, то прахом летит вся ТС?
Ровно в той же степени, что в случае с обычным советником.
А при грамотном подходе - даже в меньшей. Например, если не получилось открыться на счете №1 есть возможность открыться на счете №2. И этим сможет управлять советник-менеджер.
Как вам поможет реальная цена открытия?
Получение информации о реально открытых ордерах и корректная обработка этой информации позволяет решить ещё и важную задачу - защитить от сбоя - к примеру отключили электричество, и советник не успел записать информацию по виртуальным ордерам или ордера не успели открыться, при Вами предложенном алгоритме может возникнуть хаус, особенно если будет ошибка в файле по открытым ордерам, а в моём случае советник продолжит работать с учетом имеющейся фактической ситуации по ордерам.
Проскальзывание учитывать нужно, но для этого не обязательно наблюдать за каждой сделкой - достаточно собрать статистику и закладывать какое-то среднее значение в планируемую прибыль.
И опять таки... Проскальзывание - на центовых счетах? Проскольз на один пункт одной сделки лотом 50 нивелирует кучу проскользов от мелких сделок. Вот за ним и нужно следить.
У меня торгует единовременно порядка 27 советников, проскальзывание даже по мелким ордерам создаст ком неучтенных расходов - убытки могут быть в совокупности значительными. К примеру, рассчитал мой алгоритм ТС тейк профит на открытии бара, отправил заявку менеджеру, тот передал её исполнителю у которого в очереде 75 ордеров, которые нужно выставить/удалить/модифицировать , через минуту дошла очередь до исполнения заявки, а цена скакнула в сторону TP, да так, что наткнулась на фроз уровень, соответственно исполнитель правит TP на ближайший доступный уровень, а этот уровень выходит за пределы (для АТС ) точки разворота и цена не достигает этого уровня, что делать исполнителю - спешно закрывать ордер или как, ведь от менеджера приказов по нему больше не поступит?