Что возвращают функции Lowest и Highest - страница 6

 
Я ещё подумал, видимо в этой ситуации правильнее говорить не о подкачке, а о том, что новый бар начинает строиться не дожидаясь подкачки истории. И это как бы правильно. Но с другой стороны, представим себе торгующего эксперта. Происходит сбой связи, затем связь восстанавливается. До полной подкачки истории эксперт вполне может успеть открыть позицию на основании неправильных значений индикаторов. То есть вопрос выходит за рамки этой темы и относится к безопасности автотрейдинга вообще. Проблема непростая, конечно. Может быть выходом была бы предопределённая переменная "длина последнего непрерывного участка истории"? Индикаторы(эксперты) могли бы читать её и как-то обрабатывать ситуацию.
 
Тут может помочь хранение значения Bars (а не только Time[0]). То есть:

start()
{.....
if (PrevBars!=Bars-1) 
{
init();
PrevBars=Bars-1;
}
 
Те, кто делает серьезные торгующие эксперты, наверняка знают об этой проблеме. И какае-то обработки для такой ситуации включают в эксперт.
 
Тут может помочь хранение значения Bars (а не только Time[0])....

Вот фрагмент того фрагмента лога, из него видно, что с началом нового бара Bars увеличилась на 1, а не на число подлежащих подкачке баров. То есть это не поможет
2006.10.31 23:58:25	CZZ2 EURUSD,M1: shift=0, Bars=38230, Time[shift]=2006.10.31 22:51, High[shift]=1.2763, Low[shift]=1.2763
2006.10.31 23:58:25	CZZ2 EURUSD,M1: shift=1, Bars=38230, Time[shift]=2006.10.31 22:45, High[shift]=1.2762, Low[shift]=1.2762
2006.10.31 23:58:23	CZZ2 EURUSD,M1: shift=0, Bars=38229, Time[shift]=2006.10.31 22:45, High[shift]=1.2762, Low[shift]=1.2762



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

Ну как-то пытаться обрабатывать ситуацию можно, но похоже без кривых наворотов не обойтись. Особенно с учётом жёсткой позиции MQ по графикам без дыр.
С другой стороны терминал-то ведь знает, нужно ему подкачивать историю, или нет. Будь доступ к этому знанию из MQL, проблема решалась бы куда естественней.


 
Тогда сверяем время Time[0] и время Time[1]. Сам я только один раз боролся с такой ситуацией, поэтому практического кода сходу дать не могу.
 
Тогда сверяем время Time[0] и время Time[1]. Сам я только один раз боролся с такой ситуацией, поэтому практического кода сходу дать не могу.

Это ничего не даст, если предварительно не прикрутить код типа "график без дыр", потому что наличие дыр является штатной ситуацией в MT. Хотя на больших таймфреймах это позволит засекать почти все случаи сбоя.
 
На самом деле это в некоторй степени "демонизация" :)
Код нужно писать с максимальной защитой, так как подкачка данных может происходить не только по вине терминала, но и по вине провайдера, дата-центра, брокера, зависания компа и так далее.
 
Кстати, на всякий случай. 28. Поиск экстремумов цены - http://www.alpari-idc.ru/ru/experts/articles/29.html
 
Боюсь, код с максимальной защитой окажется непригодным для практического использования :). Поскольку торговля вообще дело рискованное, можно было бы и ограничиться разумной защитой. Но здесь речь идёт о достаточно часто возникающей ситуации. Кстати, моё заключение о большей безопасности больших таймфреймов в предыдущем посте ошибочно. Потому что до подкачки истории предыдущий бар может иметь неверные значения High, Low и Сlose, а текущий бар неверные значения High, Low и Open
 
Мда, получается, что большие таймфреймы даже опаснее мелких, потому что никаких простых способов определить правильность данных для двух последних баров я пока не вижу. Можно представить себе индикатор, висящий на минутках, и заполняющий глобальную переменную GoodHistoryDepht. Другие индикаторы сверяют эту величину с необходимой для них глубиной расчёта и принимают решения. Но из-за позиции MQ по дырам, значительная часть времени (и чем больше таймфрейм, тем большая, вплоть до полной браковки дневных баров) окажется просто непригодной для торговли. Особенно с учётом того, что сбои связи предпочитают жить на реальных счетах.