Ваши вопросы по языку MQL4

ansol

Местный знаток
Да, говорят многое о своих возможностях, но нужно быть реалистом и расчитывать на худшее. Многое еще зависит от типа счета (исполнения ордеров): если типа Instant, то еще проверку на реквоты нужно вводить, а по маркеру (скоростные счета), всегда плавающий спред и его тоже нужно учитывать и запрещать торговлю, если спред превышает какой-то заданный уровень, т.к в момент выхода новостей или в момент перехода с одного дня на другой (обычно в час ночи по Москве) спред может периодически превышать любой профит.

Да не, на Instant такого нет и быть не может, это чистый ECN.
Видимо, уходят параллельные запросы на каждый тик, а тиков в новостях до фига и больше. Вероятно, надо резать по спреду, согласен.

Если на одной паре я спред могу задать жестко, то универсальная сова должна "соображать" насчет среднего спреда?

Ну что ж, запихаем в массив это дело :) В MT5 вроде оно само по себе есть, ну да ладно!
 

vladradon

Программист
Да не, на Instant такого нет и быть не может, это чистый ECN.
Видимо, уходят параллельные запросы на каждый тик, а тиков в новостях до фига и больше. Вероятно, надо резать по спреду, согласен.

Если на одной паре я спред могу задать жестко, то универсальная сова должна "соображать" насчет среднего спреда?

Ну что ж, запихаем в массив это дело :) В MT5 вроде оно само по себе есть, ну да ладно!
Не думаю, что стоит средний спред расчитывать - лучше просто внести входную переменную и задавать для каждой пары свой ограниченный уровень по спреду, т.к. в моменты выхода новостей или перехода с одного дня торгов на другой по ECN счетам по многим парам спред очень сильно скачет и какое-то усреднение спреда исказит всю торговлю. Т.е. ели спред на паре в обычном режиме на 5-ти знаке гуляет в районе 30, то в пиках он может превышать 250 (это уже из наблюдений) и нет смысла эти скачки как-то расчитывать и усреднять. Достаточно использовать ориентировочные параметры спреда в обычном режиме торгов - без сильного тренда. Только опять же ограничение работы сова по спреду нужно грамотно вводить, с учетом того, что у тебя трал задействован. Если что, стукни в скайп - ник тот же.
 

ansol

Местный знаток
Да я понял, понял. "Средний" - понятие относительное, мы ж его можем експонентой усреднить, так что после броска все вернется на круги своя. Идея ясна.

Только это не решение - "лишние" сделки, как мне кажется, появляются именно из-за якобы многопоточной обработки, т.е. ордер ушел, а от ДЦ ни ответа ни привета и уходит второй, третий, деятый ордер, а потом это безобразие всем скопом исполняется.
 

Cemen4yk1

Местный житель
Да я понял, понял. "Средний" - понятие относительное, мы ж его можем експонентой усреднить, так что после броска все вернется на круги своя. Идея ясна.

Только это не решение - "лишние" сделки, как мне кажется, появляются именно из-за якобы многопоточной обработки, т.е. ордер ушел, а от ДЦ ни ответа ни привета и уходит второй, третий, деятый ордер, а потом это безобразие всем скопом исполняется.
эт как так, я думал если функция ордер сенд не получила ответ от сервера то и исполняться код дальше не будет, или тут какаято магия, и у вас эта функция работает по другому, она же должна получить в ответ тикет или -1, и многопоточность тут какбы вовсе и не причём, и вообще хорошо бы возвращать цену открытия ордера, а то ваш советник в упор не видит где встал предыдущий ордер, а если условие открытия выполнилось то и на следующем тике ордер ляжет рядом, кучно, так сказать, а чтоб небыло кучности - возвращайте значение ордеропенпрайс в основной код или запоминайте и храните "примерную" цену открытия позы когда ордерсенд вернула тикет
 
Последнее редактирование:

AlexeyVik

Программист mql4 mql5
Да я понял, понял. "Средний" - понятие относительное, мы ж его можем експонентой усреднить, так что после броска все вернется на круги своя. Идея ясна.

Только это не решение - "лишние" сделки, как мне кажется, появляются именно из-за якобы многопоточной обработки, т.е. ордер ушел, а от ДЦ ни ответа ни привета и уходит второй, третий, деятый ордер, а потом это безобразие всем скопом исполняется.
Такое есть только в mql5. Там есть асинхронный запрос OrderSendAsync -https://www.mql5.com/ru/docs/trading/ordersendasync

Если хочешь помощи, сформулируй вопрос так чтобы было понятно что у тебя не получается. А на такой вопрос с которого всё началось будешь получать советы про спред, своп, комиссию и прочее.
 

vladradon

Программист
Да я понял, понял. "Средний" - понятие относительное, мы ж его можем експонентой усреднить, так что после броска все вернется на круги своя. Идея ясна.

Только это не решение - "лишние" сделки, как мне кажется, появляются именно из-за якобы многопоточной обработки, т.е. ордер ушел, а от ДЦ ни ответа ни привета и уходит второй, третий, деятый ордер, а потом это безобразие всем скопом исполняется.

Можно попробовать такой вариант:
int OrdersCur; int OrdersCur1; bool OpOrder=false;// глобальные переменные
OrdersCur1=OrdersTotalMagic(Magic);
if (OrdersCur<=OrdersCur1)
{
OrdersCur=OrdersCur1;
OpOrder=true;
}
Функция подсчета открытых ордеров:
int OrdersTotalMagic(int Magic)
{
int j=0;
int r;
for (r=0;r<OrdersTotal();r++)
{
if(OrderSelect(r,SELECT_BY_POS,MODE_TRADES))
{
if (OrderMagicNumber()==Magic) j++;
}
}
return(j);
}
- возвращает количество ордеров по меджику

и, соответственно вводим саму проверку на открытие в строках 129 и 141:
if((fOpenBuy || fOpenBuy1) && OpOrder)...
if((fOpenSell || fOpenSell1) && OpOrder)...
а после 132 и 144 строк обновляем количество ордеров:
if(numorder > -1) {OrdersCur=OrdersCur+1; OpOrder=false;}
после 287-й строки вводим
OrdersCur=OrdersCur-1;
Если нигде не ошибся, то будет работать так: если была послана команда на открытие ордера, то увеличивается переменная OrdersCur на 1, и при следующем тике идет проверка, есть ли новый ордер уже в работе -
OrdersCur1=OrdersTotalMagic(Magic);
и при закрытии ордера переменная OrdersCur уменьшается на 1 соответственно, а переменная OrdersCur1 всегда имеет знаычение количества открытых ордеров по меджику.
если есть (OrdersCur<=OrdersCur1), то переменная OpOrder=true и дальше по алгоритму ордера будут открываться, а глюки по посланному запросу на открытие и новые команды на открытие ордеров будут исключены.
 
Последнее редактирование:

vladradon

Программист
Тут не пробовать надо, а разобраться в логике алгоритма и если условие на открытие сохраняется после открытия ордера, то надо разбираться с этим условием.
В плане попробовать я имел ввиду то, что эту ситуацию можно только на счете увидеть - в тесторе ее проверить невозможно, а по логике, как раз, я и даю возможные варианты применительно к коду сова.
 

vladradon

Программист
эт как так, я думал если функция ордер сенд не получила ответ от сервера то и исполняться код дальше не будет, или тут какаято магия, и у вас эта функция работает по другому, она же должна получить в ответ тикет или -1, и многопоточность тут какбы вовсе и не причём, и вообще хорошо бы возвращать цену открытия ордера, а то ваш советник в упор не видит где встал предыдущий ордер, а если условие открытия выполнилось то и на следующем тике ордер ляжет рядом, кучно, так сказать, а чтоб небыло кучности - возвращайте значение ордеропенпрайс в основной код или запоминайте и храните "примерную" цену открытия позы когда ордерсенд вернула тикет

Есть глюки в большинстве терминалов, когда от брокера зависит насколько быстро команда на исполнение ордера будет обработана и в некоторых случаях может пройти даже на скоростном счете несколько тиков, а сов при этом не будет учитывать уже посланную команду на открытие ордера (к примеру) и по своей логике будет снова по каждому тику слать команды на открытие - вот в чем проблема.
 

vladradon

Программист
Такое есть только в mql5. Там есть асинхронный запрос OrderSendAsync -https://www.mql5.com/ru/docs/trading/ordersendasync

Если хочешь помощи, сформулируй вопрос так чтобы было понятно что у тебя не получается. А на такой вопрос с которого всё началось будешь получать советы про спред, своп, комиссию и прочее.
У него сам сов на 4-ке и команды асинхрона не присутствуют - это только для 5-ки пока. А по поводу возможных решений его проблемы - нужно код смотреть для начала - просто тупо аналитикой вряд-ли получится что-то исправить.
 

Cemen4yk1

Местный житель
да бегло глянул код этого ZZ и както не увидел, а может и не нашёл там ни учета кол-ва ни возрата опенпрайса пред ордера, а "проверка" существования позы возвращает булевое значение, функция ордер модифи без функции ордер селект по вашему будет работать корректно

судя по странной функции проверки существования позы, ошибка именно там или в ещё более странной функции закрытия которая также может возвращать тру, функция учёта как я понял должна чёто там рассчитать и вернуть тру когда профит больше чего то там и ордер опентайм меньше чегото там, (немогу разобрать, похоже на эльфийский)
bool NoExistPos = ExistPosCheck(dForce) || fCloseIn;
if(StopTrading && dSCorr == 0) return;
if(IsTradeAllowed() && (fOpenBuy || fOpenSell || fOpenBuy1 || fOpenSell1) && NoExistPos)
 

vladradon

Программист
да бегло глянул код этого ZZ и както не увидел, а может и не нашёл там ни учета кол-ва ни возрата опенпрайса пред ордера, а "проверка" существования позы возвращает булевое значение, функция ордер модифи без функции ордер селект по вашему будет работать корректно

судя по странной функции проверки существования позы, ошибка именно там или в ещё более странной функции закрытия которая также может возвращать тру, функция учёта как я понял должна чёто там рассчитать и вернуть тру когда профит больше чего то там и ордер опентайм меньше чегото там, (немогу разобрать, похоже на эльфийский)
bool NoExistPos = ExistPosCheck(dForce) || fCloseIn;
if(StopTrading && dSCorr == 0) return;
if(IsTradeAllowed() && (fOpenBuy || fOpenSell || fOpenBuy1 || fOpenSell1) && NoExistPos)
Проверкка существования позы, насколько я понял, зависит от диапазонов индюка и возвращает сигнал, есть ли в этом диапазоне открытые ордера. Но это не влияет на открытие одеров в случае гэпа. По коду там все ровно на мой взгляд. Код нормальный чистый и рабочий, а в плане несанкционированного открытия ордеров - просто нужно вставлять проверки и запреты с учетом основных параметров на вход в рынок (открытие ордеров).
 

Cemen4yk1

Местный житель
Проверкка существования позы, насколько я понял, зависит от диапазонов индюка и возвращает сигнал, есть ли в этом диапазоне открытые ордера. Но это не влияет на открытие одеров в случае гэпа. По коду там все ровно на мой взгляд. Код нормальный чистый и рабочий, а в плане несанкционированного открытия ордеров - просто нужно вставлять проверки и запреты с учетом основных параметров на вход в рынок (открытие ордеров).
ну так всецело полагаться на эту функцию существования позы в диапазоне индюка было бы ненадёжным вариантом, яголосую за простой костыль :D (не открывать нов ордера если цена не ушла от опенпрайса пред ордера на опр кол-во пунктов, мой любимый костыль :laugh:)
 

vladradon

Программист
ну так всецело полагаться на эту функцию существования позы в диапазоне индюка было бы ненадёжным вариантом, яголосую за простой костыль :D (не открывать нов ордера если цена не ушла от опенпрайса пред ордера на опр кол-во пунктов, мой любимый костыль :laugh:)

Так проблема как раз и в том, что это в сове учитывается, а в случае резких скачков, команда на открытие ордера зависает у брокера на несколько тиков. Т.е. команда на открытие на данный момент уже послана и ордер должен быть открыт, но брокер этот ордер не открыл из-за какой-то задержки своей внутренней. Из-за этой задержки по каждому тику снова выдаются команды на открытие ордеров и происходит дублирование первой команды, что я в последнем варианте изменения кода и предложил, как блокировку открытия новых ордеров на случай, если команда на открытие была послана, но на текущий тик ордер еще не открылся и новая попытка открытия ордера уже не сработает, пока по предыдущей команде открытия не появится в торгах новый ордер.
 
Последнее редактирование:

ansol

Местный знаток
ну так всецело полагаться на эту функцию существования позы в диапазоне индюка было бы ненадёжным вариантом, яголосую за простой костыль :D (не открывать нов ордера если цена не ушла от опенпрайса пред ордера на опр кол-во пунктов, мой любимый костыль :laugh:)

Во-первых, почему "костыль"? Это нормально!
Во-вторых, так и сделано. Функция возвращает TRUE, если ближайший ордер дальше на "ширину канала", если ближе, то FALSE.
В тестере все ОК, а в реале почему-то даже с одной ценой умудряется открывать(не 1-2 пипса, а вообще с одинаковой ценой - я выше кусок стейта выкладывал).
Хорошо, раз маркет-исполнение, может, цена сбегала на "ширину канала", ордер послан, а исполнился по той цене, которая обратно "отползла"?
Т.е. с этим бороться не реально получается.
 

ansol

Местный знаток
В фунции OrderSend() есть параметр Slippage, который, я так понял, на маркет-исполнении игнорируется и ордеру никак не запретить исполняться по той цене, по которой надо ДЦ и не надо мне :(
 

vladradon

Программист
В фунции OrderSend() есть параметр Slippage, который, я так понял, на маркет-исполнении игнорируется и ордеру никак не запретить исполняться по той цене, по которой надо ДЦ и не надо мне :(

Теоретически такого не должно быть и при маркет исполнении запроса на открытие ордера если мы делаем запрос по текущей цене, то ордер будет открыт, если мы укладываемся в диапазон текущая цена+-слипинг ("+" для бая и "-" для селла). Но это в теории и тоже сложно проверить. Для ECN счетов слипинга в 10-30 пипсов вполне хватает, а для инстант исполнения - периодически выскакивают реквоты и на открытие и на закрытие ордеров и либо слипинг увеличивать, либо код дорабатывать для каждого момента (открытие/закрытие) отдельно. Только недавно как раз эту проблему в своем сове решал для торговли на инстанте.
 
Последнее редактирование:

ansol

Местный знаток
Теоретически такого не должно быть и при маркет исполнении запроса на открытие ордера если мы делаем запрос по текущей цене, то ордер будет открыт, если мы укладываемся в диапазон текущая цена+-слипинг ("+" для бая и "-" для селла). Но это в теории и тоже сложно проверить.

Для пятизнака у меня в OrderSend стоит "10", но я все же в эту цифирь не верю - исполнение "по рынку" же. Надо попробовать лимитники ставить, наверное?
 

alexshell

Элитный участник
Так проблема как раз и в том, что это в сове учитывается, а в случае резких скачков, команда на открытие ордера зависает у брокера на несколько тиков. Т.е. команда на открытие на данный момент уже послана и ордер должен быть открыт, но брокер этот ордер не открыл из-за какой-то задержки своей внутренней. Из-за этой задержки по каждому тику снова выдаются команды на открытие ордеров и происходит дублирование первой команды, что я в последнем варианте изменения кода и предложил, как блокировку открытия новых ордеров на случай, если команда на открытие была послана, но на текущий тик ордер еще не открылся и новая попытка открытия ордера уже не сработает, пока по предыдущей команде открытия не появится в торгах новый ордер.
Вы не правы. Пока Ордерзенд не получит ответа от сервера об открытии ордеа или неудачном открытии программа выполняться не будет,новые тики будут пропускаться.
 

alexshell

Элитный участник
Теоретически такого не должно быть и при маркет исполнении запроса на открытие ордера если мы делаем запрос по текущей цене, то ордер будет открыт, если мы укладываемся в диапазон текущая цена+-слипинг ("+" для бая и "-" для селла). Но это в теории и тоже сложно проверить.

При маркет исполнении параметр проскальзывание игнорируется.
 
Верх