пересечение линии на тиках? - страница 2

Новый комментарий
 
Пример: 
int ticket;
   while(true)
     {
      ticket=OrderSend(Symbol(),OP_BUY,1.0,Ask,3,0,0,"комментарий эксперта",255,0,CLR_NONE);
      if(ticket<=0)
        {
         int error=GetLastError();
         if(error==134) break;            // недостаточно денег
         if(error==135) RefreshRates();   // цены изменилась
        }
      else { OrderPrint(); break; }
      //---- 10 секунд ожидания
            Sleep(10000);
     }
 
У меня это работает корректно, т.к. проверка осуществляется по приходу каждого тикета, а не после if (prevtime = Time[0]) return(0);

Ты прав.
 
Это из справки =)
Поучительно здесь следующее - при попытке открыть Бай-позицию, используется значение предопределённой переменной Ask.
Эксперт "запоминает" её значение в момент запуска (начало ф-ции start()). Поэтому если с этого времени прошла секунда (следовательно, Аск мог поменяться), необходимо "освежить" данные.
Этим и занимается ф-ция RefreshRates() =)
 
Idol:
 У меня это работает корректно, т.к. проверка осуществляется по приходу каждого тикета, а не после if (prevtime = Time[0]) return(0);
Бывали случаи, когда эксперт при попытке открыть позицию по тикам, а не по сформировавшемуся бару открывает сразу две позиции, вместо одной.

Я смотрел по журналу, как это может быть и выявил, что такое случается, когда связь с интернет прерывается по каким либо причинам.

Эксперт отдает приказ открыть позицию. Коннект рвется и эксперт получает ошибку. Потом, коннект восстанавливается, эксперт смотрит в историю счета и не найдя там открытой позиции опять отдает приказ. В это время приходит подтверждение о том, что позиция по первому приказу открыта. Следом открывается вторая позиция.

В принципе это можно вылечить, если задать большую задержку на восстановление связи с провайдером после обрывов. Но не всегда поможет, т.к. может разорваться и TCP/IP коннект, без обрыва модемной связи, например, если где по пути маршрутизатор заклинил. Пока новый маршрут проложится, советник нахватает багов.

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

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

Чего мудрить над каждым тикетом, когда выясняется, что советники прошедшие успешно все тесты, начинают гнать пургу уже на демодепозитах. Только время зря терять на всякие ухищрения. А ради чего спрашивается?
 
komposter:
Это из справки =)
Поучительно здесь следующее - при попытке открыть Бай-позицию, используется значение предопределённой переменной Ask.
Эксперт "запоминает" её значение в момент запуска (начало ф-ции start()). Поэтому если с этого времени прошла секунда (следовательно, Аск мог поменяться), необходимо "освежить" данные.
Этим и занимается ф-ция RefreshRates() =)
Все очень доступно, уловил. Спасибо.
 
Reshetov:


Спасибо за информацию.

Только сейчас обнаружил Ваш ответ внутри моей старой записи (сливается).

А как быть с запаздыванием тиков (кто-нибудь сталкивался с этим?),
С этим сталкивается эксперт. Он просто игнорирует тех, кто опоздал. Что по сути правильно. Ведь разные тики по TCP/IP протоколу могут прийти на клиентский терминал не обязательно в том порядке, каком они были отправлены сервером.
Что-то мне не верится, что Bid и Ask могут приходить в беспорядочном порядке. Но если это так, то все программы основаные на тиках фалят время от времени.

Да и внутрибаровый технический анализ, если таймфрейм M30 или более тоже может выдавать неприятности. Индикаторы дрыгаются как кое-что неприличное в кое-чем неприличном. И получается, что эксперт в одном периоде (баре) получает сигнал открыть позицию, потом закрыть и так многократно. Результат - несколько непрерывных убытков на спрэдах.
Это верно, но существуют стратегии, которые зависят от резких скачков (это их хлеб). А при подобном подходе однозначно теряются крупные быстрые движения (очень часто встречается с японской валютой). В этих случаях приходится рассматривать движение внутри бара.
 
Idol:


Что-то мне не верится, что Bid и Ask могут приходить в беспорядочном порядке. Но если это так, то все программы основаные на тиках фалят время от времени.



Ты хорошо подумал прежде чем так ответить? Речь шла о том, что разные тикеты могут прийти на терминал в неправильном порядке или даже быть проигнорированы терминалом. Ask и Bid приходят в одном тикете. Т.е. если терминал получил тикет, то значит он получил и аск, бид и уникальный идентификатор этого самого тикета.
 
Reshetov:
Idol:


Что-то мне не верится, что Bid и Ask могут приходить в беспорядочном порядке. Но если это так, то все программы основаные на тиках фалят время от времени.



Ты хорошо подумал прежде чем так ответить? Речь шла о том, что разные тикеты могут прийти на терминал в неправильном порядке или даже быть проигнорированы терминалом. Ask и Bid приходят в одном тикете. Т.е. если терминал получил тикет, то значит он получил и аск, бид и уникальный идентификатор этого самого тикета.
Естественно, я не имел ввиду, что Ask и Bid приходят по отдельности друг от друга. Я имел ввиду, что эти пары приходят не по порядкую А если быть точным, то это ты говорил, а я лишь выразил удивление :) (т.к. точного ответа на этот вопрос не знаю). А это предположение ставит под сомнение корректную работу ряда моих вещей. :(
Хотя это зависит от величины этой беспорядочности.
 
Idol:
Reshetov:
Idol:


Что-то мне не верится, что Bid и Ask могут приходить в беспорядочном порядке. Но если это так, то все программы основаные на тиках фалят время от времени.



Ты хорошо подумал прежде чем так ответить? Речь шла о том, что разные тикеты могут прийти на терминал в неправильном порядке или даже быть проигнорированы терминалом. Ask и Bid приходят в одном тикете. Т.е. если терминал получил тикет, то значит он получил и аск, бид и уникальный идентификатор этого самого тикета.
Естественно, я не имел ввиду, что Ask и Bid приходят по отдельности друг от друга. Я имел ввиду, что эти пары приходят не по порядкую А если быть точным, то это ты говорил, а я лишь выразил удивление :) (т.к. точного ответа на этот вопрос не знаю). А это предположение ставит под сомнение корректную работу ряда моих вещей. :(
Хотя это зависит от величины этой беспорядочности.
Не зря техноаналитики предпочли отрисовывать бары и свечи, даже когда еще о компьютерном анализе и мечтать не приходилось. Не зря Л. Уильямс (или Вильямс), предложил замерять диапазоны для ТА. Обсасывать каждый тикет - дело неблагодарное, тем паче, что у каждого брокера свое видение цены текущего времени, что не запрещено правилами торговли. А вот исторические данные у разных брокеров совпадают. Проще говоря, если пытаться проводить ТА по каждому тикету, то следует создавать программу изучающую настроение брокера. Либо заниматься голимой пипсовкой.
Еще раз повторю, что индикаторы многократно меняют свои показания внутри бара. У меня сейчас МТС с полосами болинжера, дык там четко видно, что если цена идет вверх, то при каждом новом тикете верхняя граница болинжера то оказывается выше текущего Bid, то ниже. При движении вниз, такое же поведение наблюдается у нижней границы индюка. Т.е. торговые сигналы все время меняют свои показания на прямо противоположные в диапазоне не превышающим двойной спрэд.
 
Поправочка - речь идет все же о тиках(изменениях цен), а не о тикетах(номера ордеров).
12
Новый комментарий
Причина обращения: