Отправлено: 16.12.16 05:39. Заголовок: Паттерны ПрайсЭкшен через структуру
Игорь добрый день! Перенесу сюда свои мытарства с перепрограммированием индикатора по паттернам под свои нужды. В той ветке я показал, что кое-какие сдвиги к получению желаемого мной результата есть. В текущем варианте как вы видели по картинкам он уже отрисовывает паттерны и их цели, способен перекрасить паттерны, если его таргет пробит. Вопрос по удалению перекрытых паттернов пока откладываю на потом, поскольку возник более актуальный. Повторю здесь кусок кода, где происходят главные события с паттернами: Скрытый текст
цитата:
void FindAndShowPatterns(int index) { int startBar, patternDir,patternName; GetData(index,startBar,patternDir,patternName);
double lowPrice = ND(Low[iLowest(NULL, 0, MODE_LOW, // Нижняя граница паттерна startBar - index + 1, index)]);
double highPrice = ND(High[iHighest(NULL, 0, MODE_HIGH, // Верхняя граница паттерна startBar - index + 1, index)]); double patternHeight = highPrice - lowPrice;
Но тут где-то собака зарылась, не пойму относительно отображения EnumToString(pattern.getTarget), которая определяется отдельной функцией (кстати подобными строками перекрашиваются паттерны):
Так вот... Eсли медвежий паттерн отработан (WORKED) - то окрашивается он как отработанный, и в подписи к нему EnumToString(pattern.getTarget) пишет WORKED, а вот с бычьими почему-то не пишет... окрашивает как отработанный, но в подписи и в принте пишет что он актуальный (см. рис). Как побороть это недоразумение? Сдается мне что тут вина в implicit enum conversion в строке g_patterns[patternArray].getTarget = getTarget, его энум Скрытый текст
Кроме этого таких предупреждений еще два штуки есть по коду в строках: g_patterns[patternArray].patternType = patternDir, его Энум выглядит так Скрытый текст
Ну и все они в структуре объявлены и инициализированы вот так patternType = NONE_TYPE; patternName = NONE_INDEX; getTarget = NONE; И на всякий случай функция GetData Скрытый текст
цитата:
void GetData(int index, int& startBar, int &type, int &patternName) { //- 1 - == Определим тип найденного паттерна по направлению ===================== if(IsBullsRailsPattern(index)|| IsBUOVBPattern(index) || IsBullsPPRPattern(index)) type = BULL_TYPE; if(IsBearsRailsPattern(index) || IsBEOVBPattern(index)|| IsBearsPPRPattern(index)) type = BEAR_TYPE; //- 1 - == Конец ===============================================================
Просмотрев немного по истории, точной закономерности не выявил, но вот покажу участок, где стрелками показаны два по рассраске отработанных бычьих паттерна, между ними 8 свечей (две стрелки указывают на один и тот паттерн). Но подписи у них разные... тот что ниже слева - пишет WORKED, а тот что через 8 свечей справа - ACTUAL.
Чо к чему... не пойму А главное как так-то? Может в коде какого дополнительного условия не хватает в функции IsActualPattern? Или это не понятные примудрусти какие-то в функции строки подписи? Скрытый текст
Отправлено: 16.12.16 18:57. Заголовок: evbut пишет: Но тут..
evbut пишет:
цитата:
Но тут где-то собака зарылась, не пойму относительно отображения EnumToString(pattern.getTarget), которая определяется отдельной функцией (кстати подобными строками перекрашиваются паттерны):
Проблема в том, что нужно прерывать цикл после того, как найден пробой цели. А у Вас после этого проверяются свечи далее. Они могут не достигать цели. В итоге паттерн будет снова подписан как WORKED. Таким образом, проблема будет не только с бычьими, но и с медвежьими паттернами.
Таким образом, проблема будет не только с бычьими, но и с медвежьими паттернами.
Оно так и есть, я лишь на примере бычьих показал... Какими-то участками то бычьи, то медвежьи не верно запоминает (( Не думал, что один и тот же код по разному воспринимается переменными, в частности enum... В общем и эта проблема решилась... Оставил код определения факта отработки такой же как и для цвета, а энум оставил такой
цитата:
enum ENUM_GET_TARGET { ACTUAL, //Актуальный WORKED };
Ведь по хорошему нет же паттерна с типом NONE, неопределенным цветом, с неизвесным таргетом и прочими отсутствующими характеристиками в базе данных паттерна.
Отправлено: 19.12.16 16:23. Заголовок: evbut пишет: В обще..
evbut пишет:
цитата:
В общем и эта проблема решилась... Оставил код определения факта отработки такой же как и для цвета, а энум оставил такой
Перечисление в данном случае не при чем. Не нужно было его менять. NONE - это тип неопределенного паттерна. Он необходим для правильной работы индикатора. По всей видимости, Вы не поняли, в чем именно проблема. В таком случае попытаюсь объяснить еще раз. В приведенном коде видно, что проверка достижения цели паттерна происходит на всем участке истории от момента формирования паттерна до нулевого бара. И это правильно. Но упущен важный момент: когда найдено достижение цели паттерна, требуется прекращение дальнейшего хода цикла. К примеру, найден паттерн на баре с индексом 5. После этого запускается цикл поиска достижения цели от бара с индексом 4 до текущего бара (с индексом 0). Допустим, цель достигнута на 3-ем баре, а после этого цена откатила и больше не достигала цели. Приведенный код поставит на 3-ем баре признак WORKED, но потом перейдет к барам 2, 1 и 0, где цель не достигнута, и вернет признак ACTUAL обратно. А нужно сделать так, чтобы признак ACTUAL уже не мог быть установлен, если признак WORKED имеется.
По всей видимости, Вы не поняли, в чем именно проблема. В таком случае попытаюсь объяснить еще раз. ... Но упущен важный момент: когда найдено достижение цели паттерна, требуется прекращение дальнейшего хода цикла. ...
Этот момент я понимаю, не вразумлю только в каком месте цикла нужно брикнуть, чтоб срабатывала проверка Новый обнаруженный паттерн обозначает как ACTUAL, но не перепроверяется на актуальность база паттернов ладе на новой свече... Видимо для этого дела лучше делать отдельную функцию ведь эта проверка всего лишь условие не являющееся обязательным - if(ShowWorkedpattern) - чтобы вносить ее в БД
Отправлено: 21.12.16 07:24. Заголовок: evbut пишет: Этот м..
evbut пишет:
цитата:
Этот момент я понимаю, не вразумлю только в каком месте цикла нужно брикнуть, чтоб срабатывала проверка
Как только обнаружено достижение цели (WORKED) нужно выходить из цикла, чтобы не перезаписать вновь значение ACTUAL. Хотя в Вашем случае более уместно добавить проверку в цикл k:
Отправлено: 21.12.16 05:45. Заголовок: Scriptong пишет: К ..
Scriptong пишет:
цитата:
К примеру, найден паттерн на баре с индексом 5. После этого запускается цикл поиска достижения цели от бара с индексом 4 до текущего бара (с индексом 0). Допустим, цель достигнута на 3-ем баре, а после этого цена откатила и больше не достигала цели. Приведенный код поставит на 3-ем баре признак WORKED, но потом перейдет к барам 2, 1 и 0, где цель не достигнута, и вернет признак ACTUAL обратно. А нужно сделать так, чтобы признак ACTUAL уже не мог быть установлен, если признак WORKED имеется.
А принты не говорят об этом, а показывают отработан паттерн. Вывел специально текстовое описание паттерна, которое показывает тип паттерна и его отработанность... Все говорит о том, что Ваша верная логическая цепочка не работает дальше момента, когда цель достигнута на 3-ьем баре, на барах со 2 по 0 факт WORKED не переписывается. Или я самообманываюсь?
Объясните почему в энуме по отработке стоит оставить NONE? Ведь по сути у паттерна не может быть такого состояния. Как только паттерн обнаружился он по факту ACTUAL пусть даже на долю секунды на минутном графике при выходе новостей и бешенной скорости изменения цены.
Игорь, подскажите, как заставить индикатор рисовать в тестере? Тяжко на минутном графике даже выжидать как он работает в реале )) Но таки высмотрел такой момент.Функцию FindAndShowPatterns малость переделал Скрытый текст
цитата:
void FindAndShowPatterns(int index) { int startBar=GetStartBar(index); double lowPrice=Low[iLowest(NULL,0,MODE_LOW,// Нижняя граница паттерна startBar-index+1,index)];
double highPrice=High[iHighest(NULL,0,MODE_HIGH,// Верхняя граница паттерна startBar-index+1,index)]; double patternHeight=highPrice-lowPrice;
Как бы функция работает и новые паттерны рисует, и алерт срабатывает но...- почему-то не перекрашивает паттерны в цвет отработанных в режиме онлайн, только после обновления графика или переключением таймфреймов. В OnCalculate вот так прописано
цитата:
int total; int limit=GetRecalcIndex(total,rates_total,prev_calculated); // Определим первый расчетный бар
for(int i=limit; i>0; i--) // Обработаем все новые бары { FindAndShowPatterns(i); ChartRedraw(); } return rates_total;
Как я и предполагал, здесь недоработка. Функция не содержит кода, который изменяет цвет объекта, если он уже создан. Посмотрите внимательно: если объект уже существует, то будет изменена только его цена, но не цвет. Нужно в таких случаях изменять еще и цвет:
цитата:
void ShowRectangle(string name,datetime time1,double price1,datetime time2, double price2,string toolTip,color clr) { if(ObjectFind(name)<0) // Если объект не существует { ObjectCreate(0,name,OBJ_RECTANGLE,0,time1,price1,time2,price2); ObjectSetInteger(0,name,OBJPROP_SELECTABLE,false); ObjectSetInteger(0,name,OBJPROP_WIDTH,LineWidth); ObjectSetInteger(0,name,OBJPROP_STYLE,LineStyle); ObjectSetInteger(0,name,OBJPROP_COLOR,clr); ObjectSetInteger(0,name,OBJPROP_BACK,FillRectangle); ObjectSetString(0,name,OBJPROP_TOOLTIP,toolTip); return; } ObjectMove(name,0, time1, price1); // Перемещение существующего объекта ObjectMove(name, 1, time2, price2); // Перемещение существующего объекта ObjectSetInteger(0,name,OBJPROP_COLOR,clr); }
Как я и предполагал, здесь недоработка. Функция не содержит кода, который изменяет цвет объекта, если он уже создан. Посмотрите внимательно: если объект уже существует, то будет изменена только его цена, но не цвет. Нужно в таких случаях изменять еще и цвет:
Добавил не достающую строку, всю равно не перекрашивает (( Вся перекраска происходит только после обновления графика или в момент инициализации индикатора. Такое ощущение, что чего-то не хватает, где-то чего не учел я - не соображу... уже голову наизнанку вывернул. Уже и функцию цвета переделал под манер функции проверки ACTUAL или WORKED паттерн (ее пока оставил, ибо не удобно следить). Видно надо перекур сделать ))
//+------------------------------------------------------------------+ //| | //+------------------------------------------------------------------+ enum ENUM_GET_TARGET { NONE, ACTUAL,//Актуальный WORKED }; //+------------------------------------------------------------------+ //| | //+------------------------------------------------------------------+ enum ENUM_PATTERN_TYPE { NONE_TYPE, //0 - No pattern BULL_TYPE, //1 - Bull pattern BEAR_TYPE, //2 - bear pattern }; //+------------------------------------------------------------------+ //| | //+------------------------------------------------------------------+ enum ENUM_FUNCTION_RESULT { FUNCTION_RESULT_OK, // The successful ending of function run FUNCTION_RESULT_ALRIGHT, // The not successful ending of function run but no has critical errors FUNCTION_RESULT_FATAL // The fatal error ending of function run }; //+------------------------------------------------------------------+ //| | //+------------------------------------------------------------------+ enum ENUM_PATTEN_NAME { NONE_INDEX=-1, RAILS_= 0, OVB_ = 1, PPR_ = 2 }; //+------------------------------------------------------------------+ //| | //+------------------------------------------------------------------+ struct Pattern { ENUM_PATTERN_TYPE patternType; // Тип паттерна (бычий, медвежий) ENUM_PATTEN_NAME patternName; // Индекс имени паттерна ENUM_GET_TARGET getTarget; // Отработан ли патерна int leftBarIndex; // Индекс левого бара паттерна int rightBarIndex; // Индекс правого бара паттерна double patternLowPrice; // Нижняя цена паттерна double patternHighPrice; // Верхняя цена паттерна double patternHeight; // Высота паттерна double patternTarget; // Уровень цели бычьего паттерна color patternColor; // ЦВет паттерна
//+-------------------------------------------------------------------------------------+ //| Удаление всех объектов, созданных индикатором | //+-------------------------------------------------------------------------------------+ void DeleteAllObjects() { for(int i=ObjectsTotal()-1; i>=0; i--) if(StringSubstr(ObjectName(i),0,StringLen(PREFIX))==PREFIX) ObjectDelete(ObjectName(i)); } //+-------------------------------------------------------------------------------------+ //| Определение индекса бара, с которого необходимо производить перерасчет | //+-------------------------------------------------------------------------------------+ int GetRecalcIndex(int &total,const int ratesTotal,const int prevCalculated) { total=ratesTotal-3;
return true; } //+-------------------------------------------------------------------------------------+ //| Display Value | //+-------------------------------------------------------------------------------------+ bool ShowIndicatorData(int limit, int total) { for (int i = limit; i > 0; i--) ProcessBar(i);
return true; } //+-------------------------------------------------------------------------------------+ //| Custom indicator iteration function | //+-------------------------------------------------------------------------------------+ int OnCalculate(const int rates_total, const int prev_calculated, const datetime &time[], const double &open[], const double &high[], const double &low[], const double &close[], const long &tick_volume[], const long &volume[], const int &spread[]) { // - 1 - == Организационные действия ==================================================== int total; // Индекс наиболее раннего в истории.. // ..бара int limit=GetRecalcIndex(total,rates_total,prev_calculated); // Определим первый расчетный бар if (!ShowIndicatorData(limit, total)) g_activate = false;
Добавил не достающую строку, всю равно не перекрашивает (( Вся перекраска происходит только после обновления графика или в момент инициализации индикатора. Такое ощущение, что чего-то не хватает, где-то чего не учел я - не соображу... уже голову наизнанку вывернул. Уже и функцию цвета переделал под манер функции проверки ACTUAL или WORKED паттерн (ее пока оставил, ибо не удобно следить). Видно надо перекур сделать ))
Давайте тогда уже весь индикатор (приаттачьте через dropmefiles или любой другой ресурс). Ведь по обрывку кода трудно что-то сказать.
С Новым Годом, Игорь! Спасибо Вам за неизменную поддержку и Ваш профессионализм в прошлом году! В новом году желаю успеха в реализации Ваших задумок, благополучия и мирного неба Вам и вашей семье!
Посмотрел. Не увидел в коде участка, отвечающего за перерисовку паттерна. Так, функция ProcessBar обслуживает только новые бары. Она никогда не повторяет расчет одного и того же бара. Поэтому паттерн может быть только найден. Его дополнительная проверка не производится.
Возможно проверка задумывалась в функции IsActualPattern(), но эта функция нигде в коде не вызывается. Даже, если она будет вызвана, то это ни к чему не приведет, т. к. функция меняет лишь статус паттерна, но не производит его перерисовку.
Возможно проверка задумывалась в функции IsActualPattern(), но эта функция нигде в коде не вызывается. Даже, если она будет вызвана, то это ни к чему не приведет, т. к. функция меняет лишь статус паттерна, но не производит его перерисовку.
Собственно да, один из вариантов реализации отображения отработки паттернов было как раз через эту функцию, что-то в этом духе
int limit=GetRecalcIndex(total); // Определим первый расчетный бар
for (int i = limit; i > 0; i--) { FillPatternsDB(i); //функция наполнения базы паттернов типа void
for(int k = ArraySize(g_patterns)-1; k>=0; k--) ReDrawPattern(g_patterns[k]); //собственно отрисовка }
WindowRedraw();
От вашего варианта как во Всплеск и Полка пока отошел... и по сему понимаю, что кривая конструкция, но с праздниками этими все в голове перемешалось... В тестере вроде рисуется с использованием этой функции... Новый паттерн отрисовывает в сине-красных цветах, и даже отработанные показывает, только не на том месте где он действительно есть, а со смещением к нулевому бару, а точней к тому бару на котором была зафиксирована его отработка паттерна (ВИДЕОзаписал ).
Решение кажется нашлось... в функции GetUniqueID было внесено отображение факта отработки паттерна. ТАк вот получалось, что индикатор не находил прямоугольник патерна с подписью ACTUAL, потому что он уже был WORKED, поэтому рисовал его поновой в другом месте..
Ну это уж совсем никудышное решение. Во-первых, производится повторение одних и тех же действий (вызов функции FillDBPatterns() теперь будет дважды на одном и том же баре и, приводит к дублированию паттернов в массиве - см. журнал). Во-вторых, дважды производится определение отработки паттерна (логика размазана по двум функциям RecolorPattern() и ReDrawPattern()), что затрудняет понимание кода.
Также в процессе просмотра кода увидел основную проблему: при нахождении паттерна запонимаются номера баров, где он найден (члены leftBarIndex и rightBarIndex структуры Pattern). При таком подходе требуется поддерживать номера баров в дальнейшем, т. к. номер бара - не уникальный идентификатор. Номера баров изменяются в момент прихода нового бара. В итоге тот бар, который сохранен для паттерна оказывается невалидным. Поэтому нужна поддержка индексов. Или же, лучший подход, запоминать не индекс бара, в время открытия баров. Это уже уникальные данные, которые никогда не изменяться.
Игорь, подскажите, достаточно ли будет на этом этапе в функции наполнения БД паттернов
цитата:
int patternArray=ArraySize(g_patterns); for (int i = patternArray - 1; i >= 0; i--) if (g_patterns.patternType == newPattern && g_patterns.patternName == newPatternName && g_patterns.leftBarIndex == startBar && g_patterns.rightBarIndex == endBar ) return FUNCTION_RESULT_ALRIGHT;
прописать для проверки только эти характеристики паттерна или же нужно проверить все согласно прописанного в структуре (за исключением patternTarget, getTarget и patternColor?
цитата:
ENUM_PATTERN_TYPE patternType; // Тип паттерна (бычий, медвежий) ENUM_PATTEN_NAME patternName; // Индекс имени паттерна ENUM_GET_TARGET getTarget; // Отработан ли патерна int leftBarIndex; // Индекс левого бара паттерна int rightBarIndex; // Индекс правого бара паттерна double patternLowPrice; // Нижняя цена паттерна double patternHighPrice; // Верхняя цена паттерна double patternHeight; // Высота паттерна double patternTarget; // Уровень цели бычьего паттерна color patternColor; // ЦВет паттерна
И еще несколько вопросов по коду функции из инидкатора Всплеск и полка
цитата:
ShowIndicatorData(int limit, int total) { if (limit > 1) { ArrayResize(g_patterns, 0, ARRAY_RESERVE_SIZE); g_lastBuyPatternRegFractalTime = 0; g_lastSellPatternRegFractalTime = 0; }
if (limit == 1) for (int i = ArraySize(g_patterns) - 1; i >= 0; i--) { g_patterns.leftBarIndex++; g_patterns.rightBarIndex++; }
for (int i = limit; i >= 0; i--) if (!ProcessBar(i)) return false;
Под limit подразумевается количество баров или собственно ограничение в барах? Да и в целом я правильно понимаю результат этой функции: при limit > 1 задаем новый размер массива паттернов, при limit == 1 - изменяем номера баров границы паттернов, и в последнем случае отрисовываем что желаем?
Игорь, подскажите, достаточно ли будет на этом этапе в функции наполнения БД паттернов прописать для проверки только эти характеристики паттерна или же нужно проверить все согласно прописанного в структуре (за исключением patternTarget, getTarget и patternColor?
Пока суть вопроса неясна. Конкретизируйте, пожалуйста.
Отправлено: 26.12.16 13:33. Заголовок: evbut пишет: Под li..
evbut пишет:
цитата:
Под limit подразумевается количество баров или собственно ограничение в барах?
В данном случае то, что представляет собой переменная limit, описано в функции OnCalculate:
цитата:
int total; int limit = GetRecalcIndex(total, rates_total, prev_calculated);
if (!ShowIndicatorData(limit, total)) g_activate = false;
В свою очередь, GetRecalcIndex прокомментирована: Determination of bar index which needed to recalculate. Это означает, что переменная limit получает индекс бара, с которого на текущем тике необходимо вычислять значения индикатора. Так, при первом запуске индикатора limit получит индекс самого левого бара в истории минус 2 (ratesTotal - 3), если значение параметра "Количество баров отображения" равно 0. В пртивном случае переменная limit будет равна значению этого параметра. При повторном вызове функции OnCalculate индикатора значение limit будет равно 0, если на текущем баре уже были вычисления, и 1, если образовался новый бар. Больше 1 при повторном вызове OnCalculate переменная limit будет только в случае подкачки истории котировок. Такой подход позволяет оптимизировать работу индикатора: с каждым новым тиком производится перерасчет только вновь поступивших данных. В противном случае индикатор на каждом тике производил бы перерасчет всей имеющейся истории.
Такой подход позволяет оптимизировать работу индикатора: с каждым новым тиком производится перерасчет только вновь поступивших данных. В противном случае индикатор на каждом тике производил бы перерасчет всей имеющейся истории.
Выходит проблема не перекрашивания отработанных паттернов зарыта в этой области. Значит саму функцию пересчета баров необходимо сделать так, чтобы на каждом новом баре индикатор в массиве паттернов искал все ACTUAL и от самого левого из них перепроверил их актуальность.
Отправлено: 13.01.17 22:34. Заголовок: Scriptong пишет: У ..
Scriptong пишет:
цитата:
У меня такое не наблюдается.
Странно очень... Такое отмечается, когда переключаешься с меньшего фрейма на больший. Однако в функцию ShowIndicatorData прописал
цитата:
if(limit > 1) ArrayResize(g_patterns,0);
и кажется перестало такое безобразие мельтешить... Не критично конечно, но мешает.
Такой еще момент. Решил добавить опционально удаление перекрытых паттернов. Код такой
цитата:
//+-----------------------------------------------------------------------------+ //| Process specify pattern | //+-----------------------------------------------------------------------------+ bool IsNeedToDeletePattern(const Pattern &pattern, int index) { if(OverLaidPattern) return false;
for (int i = index; i < pattern.leftBarIndex; i++) { if(NamePattern(i) < 0) { return false; i--; } } return true; } //+-----------------------------------------------------------------------------+ //| Delete specify element from array | //+-----------------------------------------------------------------------------+ template<typename T> void DeleteElementFromArray(T &array[], int elementToDelete) { int arraySize = ArraySize(array); if (arraySize == 0) return;
array[elementToDelete] = array[arraySize - 1]; ArrayResize(array, arraySize - 1, ARRAY_RESERVE_SIZE); } //+-----------------------------------------------------------------------------+ //| Process on overlaid pattern | //+-----------------------------------------------------------------------------+ void ProcessPatterns(int index) { for (int i = ArraySize(g_patterns) - 1; i >= 0; i--) if (IsNeedToDeletePattern(g_patterns, index-1)) DeleteElementFromArray(g_patterns, i); }
Судя по картинкам - удаляет те двухсвечные, паттерны, которые находятся как бы внутри трехсвечного паттерна. Однако "чистка" среди трехсвечных не происходит (подчеркнул на картинке явное наложение. По идее синий паттерн должен быть удален). Каким образом заставить и такие участки удалять или где-то в коде косякнул?
Странно очень... Такое отмечается, когда переключаешься с меньшего фрейма на больший. Однако в функцию ShowIndicatorData прописал
Проверил, переключившись а М1 на Н1. Все ОК.
evbut пишет:
цитата:
и кажется перестало такое безобразие мельтешить... Не критично конечно, но мешает.
Это, кстати, правильный ход. Только лучше такой код разместить в GetRecalcIndex() после строки ObjectsDeleteAll(). Ведь объекты удаляются, а массив g_patterns в итоге будет содержать паттерны-дубликаты.
evbut пишет:
цитата:
Такой еще момент. Решил добавить опционально удаление перекрытых паттернов. Код такой
Нужно знать, откуда вызывается этот код. В самом же коде есть логическое упущение - в функции IsNeedToDeletePattern() проверяется только совпадение правых краев паттернов, а далее - нет. Кстати, в чем смысл такой конструкции?
цитата:
if(NamePattern(i) < 0) { return false; i--; }
Во-первых, после return ничего не может выполняться. Во-вторых, если допустить, что требуется декремент значения i при выполнении условия NamePattern, то все равно смысла нет - происходит выход из функции, значение переменной i теряется. Или же декремент должен был быть за фигурной скобкой? Но тогда получим бесконечный цикл...
Отправлено: 24.01.17 11:03. Заголовок: evbut пишет: В нее ..
evbut пишет:
цитата:
В нее заложен смысл, что если нет именованного паттерна, то и проверять не имеет смысла.
Так а зачем после return происходит декремент? Ведь после return ничего не может выполняться в том же блоке. Возможно, скобкой ошиблись. Но тогда, когда исправите положения скобок, получите зависание индикатора.
Отправлено: 19.01.17 18:50. Заголовок: И снова здрасьте... ..
И снова здрасьте... С удалением перекрытых паттернов еще однако разгребать и разгребать... Но вот решил сделать выбор отображения паттернов по отдельности, а не кучей... Уже и не помню ту версию что высылал вам... В общем функция ShowIndicatorData выглядит теперь так
цитата:
void ShowIndicatorData(int limit, int total) { if(limit > 1) ArrayResize(g_patterns,0);
Включаю по отдельности отображение то рельс, то ППР... И вот при отображении только паттерна Рельсы на некоторых участках встречается вот такое как для бычьих так и для медвежьих направлений (см рис), что совсем не понятно откуда всплывает - Прямоугольник показывает ППР да и выглядит это комбинация свечей как ППР, а в подписи Рельсы (( В настройках параметры Рельс стоят 20 и 10
Отправлено: 24.01.17 11:01. Заголовок: evbut пишет: Уже и ..
evbut пишет:
цитата:
Уже и не помню ту версию что высылал вам
Вот и мне трудно поддерживать именно тот исходник, с которым Вы работаете, отслеживая изменения по Вашим постам. Пожалуйста, прикрепляйте свою последнюю версию, с которой работаете. Тогда легче будет поддерживать предметный разговор. А иначе я просто теряюсь в догадках.
Вот и мне трудно поддерживать именно тот исходник,
ЗДЕСЬ можно взять крайнюю версию индикатора... Всё перерыл в коде... не найду отчего так отрисовывает и подписывает (( Все функции поиска паттернов взяты из вашего индикатора, за исключением WRB. Поглядите своим опытным глазом, пожалуйста... Ссылка живая будет 7 дней.
Отправлено: 30.01.17 21:52. Заголовок: evbut пишет: И вот..
evbut пишет:
цитата:
И вот при отображении только паттерна Рельсы на некоторых участках встречается вот такое как для бычьих так и для медвежьих направлений (см рис), что совсем не понятно откуда всплывает - Прямоугольник показывает ППР да и выглядит это комбинация свечей как ППР, а в подписи Рельсы (( В настройках параметры Рельс стоят 20 и 10
Проблема кода в том, что решение о регистрации паттерна разбросано по нескольким независимым функциям. Так, в основной функции FillPatternsDB несколько раз производятся одни и те же действия. Сначала определяется направление паттерна:
цитата:
ENUM_PATTERN_TYPE newPattern = PatternDir(index);
Сразу заметим, что функция PatternDir() вызывает функции IsBullsRailsPattern(), IsBUOVBPattern(), IsBullsPPRPattern() и IsBullsWRBPattern(). Причем этот вызов никак не реагирует на значения настроечных параметров, определяющих, какой паттерн следует искать. Как бы мы не настраивали индикатор, все равно он будет искать все включенные в него паттерны. Уже просчет.
Возвращаемся в FillPatternsDB(). Следующая строка:
определяет имя паттерна. Как это делается? Снова через вызов функций IsBullsRailsPattern(), IsBUOVBPattern(), IsBullsPPRPattern() и IsBullsWRBPattern(). Но ведь мы вызывали эти функции для бара index! То есть снова выполняется уже проделанная работа. Если идти далее, то видим третью строку FillPatternsDB():
цитата:
int startBar = GetStartBar(index);
Причем функция GetStartBar() вновь оперирует теми же самыми функциями: IsBullsRailsPattern(), IsBUOVBPattern(), IsBullsPPRPattern() и IsBullsWRBPattern(). То есть эти функции были вызваны три раза на одном и том же баре. Но и это еще не беда. Беда в том, что функции вызываются каждый раз в разном порядке:
1. В PatternDir() порядок такой: Рельсы, OVB, PPR, WRB. 2. В NamePattern: Рельсы, OVB, PPR, WRB. 3. В GetStartBar: PPR, WRB, OVB, Рельсы.
В итоге получается каша. Если на одном и том же баре имеется несколько разных паттернов, то имя и направление берется от одного паттерна, а номер стартового бара - от другого.
Вывод. Таким образом, по озвученной проблеме рецепт такой: во всех функциях сделать единый порядок проверки паттернов, чтобы не было расхождений в регистрации.
По всему коду вывод другой: сделать централизованную регистрацию паттернов, без необходимости поиска паттернов на одном баре несколько раз. То есть, вызвав условную функцию ЕстьЛиПаттернНаЭтомБаре(), нужно сразу получить и тип паттерна, и его направление, и стартовый бар. Именно в этой функции следует разместить проверки значений настроечных параметров, указывающих, какой паттерн следует искать, а какой - нет. Это значительно ускорит работу индикатора. Кроме того нужно заранее продумать приоритеты паттернов. В тех случаях, когда на одном баре возникает сразу несколько паттернов и все они подлежат отображению, то из найденных следует выбрать только один паттерн, с наибольшим приоритетом.
сделать централизованную регистрацию паттернов, без необходимости поиска паттернов на одном баре несколько раз.
цитата:
Это значительно ускорит работу индикатора
В целом омтечается заторможенность работы индикатора в этом виде кода, особенно когда историю большую ставишь... Если я правильно понял, стоит вернуть ваши функции FindAndShow-бла-блаPattern, что позволит ускорить его работу... Или будет достаточно расширить функционал функции FillPatternDB?
цитата:
В тех случаях, когда на одном баре возникает сразу несколько паттернов и все они подлежат отображению, то из найденных следует выбрать только один паттерн, с наибольшим приоритетом.
Не совсем понимаю как задать приоритет паттернов программно. Переменная указанная ниже не решает этот вопрос?
Отправлено: 31.01.17 21:07. Заголовок: evbut пишет: Или бу..
evbut пишет:
цитата:
Или будет достаточно расширить функционал функции FillPatternDB
Нужно сделать так, чтобы на одном и том же баре не повторялись одни и те же действия. То есть вместо нескольких отдельных вызовов разных функций (PatternDir(), NamePattern(), GetStartBar()) нужно сделать одну функцию, которая все это вычисляет. Ведь все равно задача каждой из этих функций сводится к вызову одних и тех же функций. В итоге вместо трех вызовов функций IsBullsRailsPattern(), IsBUOVBPattern(), IsBullsPPRPattern() и IsBullsWRBPattern() будет лишь один их вызов. Кстати, далее по коду FillPatternsDB() следует еще один вызов PatternDir(). Для чего? Ведь результат ее вызова уже кеширован в переменной newPattern. Вообще это очень плохая практика - прибегать к вызову одной и той же функции в прилежащих кусках кода. Ведь в этом случае Вы делаете упор на то, что результат вычислений функции будет один и тот же. Но это бывает далеко не всегда. К примеру, имеется такая распространенная ошибка у программистов, которая приводит к получению фатальной ошибки zero divide:
цитата:
if (AccountEquity() != 0.0) fPercent = fProfit / AccountEquity()
Здесь, казалось бы, перед операцией деления имеется проверка результата функции на равенство нулю. Но между двумя вызовами этой функции проходит время (пусть небольшое). За этот период времени значение, возвращаемое AccountEquity(), может измениться и стать равным нулю. Правильный подход в данном случае такой:
То есть вместо нескольких отдельных вызовов разных функций (PatternDir(), NamePattern(), GetStartBar()) нужно сделать одну функцию, которая все это вычисляет.
Не знаю насколько оптимальное решение, но все эти функции вывел в FillPatternsDB (переименовал ее трохи) Скрытый текст
static datetime lastAlert = 0; if(newPattern != 0) { int patternArray=ArraySize(g_patterns); // внесем его в Базу паттернов
if(ArrayResize(g_patterns,patternArray + 1, ARRAY_RESERVE_SIZE) < 0) Alert(g_isRussianLang? ": Недостаточно памяти для продолжения работы программы. Индикатор отключен.": ": Not enough memory to continue work the program. Indicator is turned off.");
//запишем в базе.. g_patterns[patternArray].patternType = newPattern; //.. тип паттерна g_patterns[patternArray].patternName = newPatternName; //.. название паттерна g_patterns[patternArray].leftBarIndex = startBar; //.. левая граница g_patterns[patternArray].rightBarIndex = endBar; //.. правая граница g_patterns[patternArray].patternHighPrice = highPrice; //.. верхняя граница g_patterns[patternArray].patternLowPrice = lowPrice; //.. нижняя граница
Сделать везде одинаковый порядок вызова функций, определяющих наличие паттерна. Паттерн, обрабатываемый первым, получит наивысший приоритет.
И с порядком теперь получается порядок )) По поводу перекрытости паттернов ломаю голову дальше в плане установления приоритетности паттернов... Ведь нигде в коде не обозначено, что последовательность имен паттернов в enum ENUM_PATTEN_NAME
задает приоритет PPR над всеми остальными. Или только в совокупности расположения в ENUM_PATTEN_NAME и такой же последовательности вызова функций определяет приоритет? Этот момент не укладывается в голове )) Еще такой момент: необходимо снизить нагрузку на компьютер. Найденное большое количество паттернов записанное в массив нагружает систему... а если много пар в работе - зависон полный будет. Решение проблемы пока такое вижу - запись параметров найденных и неперекрытых паттернов в файл, откуда функция ShowPatterns будет считывать исторические данные по символу и отрисовывать, а массив g_patterns - либо обнулять, либо пусть помнит не более 20-30 последних найденных паттернов, при деинициализации индикатора скидывал бы их в этот файл. Как по вашему рациональный подход или есть более оптимальный вариант, который мне пока в голову не приходит?
PS. Еще раз почитав код индикатора "Всплеск и полка" пришел к окончательному выводу - держать в памяти отработанные паттерны в принципе нет - они только нагружают ПК.. поэтому концовку представленной выше функции будет выглядеть так
цитата:
//== и подадим сигнал SignalOnPattern(g_patterns[patternArray], isAlert,index,lastAlert,soundpattern); } //== Если включен флаг "Не показывать перекрытые паттерны удалим лишние if(!OverLaidPattern) { ProcessPatterns(index); } // == Раскрасим патерны и удалим отработанные из массива for(int j = ArraySize(g_patterns)-1; j >= 0; j--) { ReDrawPattern(g_patterns[j]); if(g_patterns[j].getTarget == WORKED) DeleteElementFromArray(g_patterns, j); } }
А запись в файл полезно будет лишь в случае исследования паттернов на предмет факта отработки по имени паттерна, его направлению и сроку отработки (сколько времени прошло с момента формирования до момента отработки).
Отправлено: 06.02.17 16:30. Заголовок: evbut пишет: Не зна..
evbut пишет:
цитата:
Не знаю насколько оптимальное решение, но все эти функции вывел в FillPatternsDB (переименовал ее трохи)
Не самое плохое решение Можно и так. В итоге приоритет поиска паттернов в данном случае получается следующий:
1. PPR (т. к. его поиск идет самым последним, а, значит, паттерн при нахождении затрет любой другой паттерн) 2. WRB 3. OVB 4. Рельсы
Сразу возникает вопрос: если на одном баре было зарегистрировано сразу четыре разных паттерна (гипотетически), и нам заранее известно, что будет принят только PPR, то зачем производился поиск всех остальных паттернов? Ответ на этот вопрос: не нужно так делать. Паттерн с наивысшим приоритетом должен разыскиваться первым. Если же этот паттерн найден, то к поиску других паттернов даже приступать не стоит:
Отправлено: 06.02.17 16:32. Заголовок: evbut пишет: И с по..
evbut пишет:
цитата:
И с порядком теперь получается порядок )) По поводу перекрытости паттернов ломаю голову дальше в плане установления приоритетности паттернов... Ведь нигде в коде не обозначено, что последовательность имен паттернов в enum ENUM_PATTEN_NAME
Приоритеты поиска паттернов не зависят от последовательности объявления паттернов в перечислении. Приоритет назначается программно. Как именно - показал постом выше.
Отправлено: 06.02.17 16:36. Заголовок: evbut пишет: Еще та..
evbut пишет:
цитата:
Еще такой момент: необходимо снизить нагрузку на компьютер. Найденное большое количество паттернов записанное в массив нагружает систему... а если много пар в работе - зависон полный будет. Решение проблемы пока такое вижу - запись параметров найденных и неперекрытых паттернов в файл, откуда функция ShowPatterns будет считывать исторические данные по символу и отрисовывать, а массив g_patterns - либо обнулять, либо пусть помнит не более 20-30 последних найденных паттернов, при деинициализации индикатора скидывал бы их в этот файл. Как по вашему рациональный подход или есть более оптимальный вариант, который мне пока в голову не приходит?
Так, для справки: файловые операции, даже на SSD-диске многократно уступают по скорости в сравнении с оперативной памятью. Именно поэтому все программы для совей работы записывают данные в оперативную память, а не в файл. В файлы данные пишутся для хранения, пока программа не работает. Проблема большой нагрузки в данном случае не в том, что происходит работа с памятью, а в том, что программа занимается лишней работой. Так, посмотрев работу программы в профилировщике, сразу видим корень зла: Это функция IsPatternWorked(). В ней каждый паттерн на каждом новом баре проверяется на предмет отработки (достижения цели). Более того, на каждом баре функция вызывается дважды: в FindPatternsAndFillDB() и в ReDrawPattern(). Лишняя работа заключается в том, что сразу при обнаружении паттерна производится проход по все истории от момента возникновения паттерна до текущего момента времени. Зачем? Ведь у нас уже имеется цикл, идущий по истории (в ShowIndicatorData()). Пусть он и задает текущий бар, на котором нужно проверять отработку паттерна. При таком подходе в IsPatternWorked исчезнет цикл, что сразу решит проблему быстродействия.
Отправлено: 07.02.17 06:18. Заголовок: Так, развейте не сты..
Так, развейте не стыковку по вашим высказываниям. Порядок приоритетности я брал из статьи по индикатору "Простые паттерны" (и в нем же порядок поиска паттернов располагается по возрастающему, с ваших слов в статье, приоритету - от "Inside Bar" до Island Reversal) и здесь Scriptong пишет:
цитата:
1. PPR (т. к. его поиск идет самым последним, а, значит, паттерн при нахождении затрет любой другой паттерн)
И далее по тексту читаю Scriptong пишет:
цитата:
Паттерн с наивысшим приоритетом должен разыскиваться первым.
. Так как же на самом деле правильно?
Лирическое отступление ))) Логически как бы понятно, что чем реже встречается паттерн, тем сильнее он. Среди двух баровых - "Поглащение" будет сильней Рельс. Среди трех баровых из моего списка наверно предпочтение нужно отдать WRB... Но тот же PPR чаще встречается, чем теже Рельсы или Поглащение... И думается мне, что приоритетность на одном баре нужно определять как в поговорке "Кто первый встал, того и тапки"
Использование такого подхода получается частично избавляет от необходимости удалять перекрытые паттерны. А пока что не могу избавиться от функции
Чтобы реализовать удаление перекрытых... Как говориться: "в голове вертится, а на язык не идет"... т.е. понимаю, что функционал удаления, можно воткнуть также в функцию FindPatternsAndFillDB на этапе нахождения минимум первых 3ёх любых паттернов, чтобы просто не давать накладывающимся паттернам записываться в БД согласно их приоритету.
Спасибо за наводку с профилированием - теперь знаю для чего нужна эта кнопочка )))
Отправлено: 17.02.17 12:00. Заголовок: evbut пишет: Так, р..
evbut пишет:
цитата:
Так, развейте не стыковку по вашим высказываниям. Порядок приоритетности я брал из статьи по индикатору "Простые паттерны" (и в нем же порядок поиска паттернов располагается по возрастающему, с ваших слов в статье, приоритету - от "Inside Bar" до Island Reversal) и здесь
Все зависит от логики программы. Можно построить логику так, что, найдя паттерн, будет произведен выход из функции поиска. На мой взгляд, это наиболее приемлемый вариант, т. к. отсекаются лишние действия. В предложенном Вами варианте структура функции создана иначе (наоборот): так, что происходит поиск всех паттернов подряд и запись результата поиска в одну и ту же переменную. Поэтому логично, что паттерн, поиск которого следует последним, затрет информацию о всех ранее найденных паттернах.
Таким образом, по хорошему, функцию FindPatternsAndFillDB нужно разбить на несколько более мелких функций, сделав поиск паттерна с наивысшим приоритетом первым. Если паттерн найден, то остальные даже не разыскиваются. А вот если паттерн не найден, то происходит переход к поиску следующего паттерна.
Таким образом, по хорошему, функцию FindPatternsAndFillDB нужно разбить на несколько более мелких функций, сделав поиск паттерна с наивысшим приоритетом первым. Если паттерн найден, то остальные даже не разыскиваются. А вот если паттерн не найден, то происходит переход к поиску следующего паттерна.
Функцию на мелкие не стал разбивать - но предложенный вами вариант
позволил сократить число обращение функций ккаждому бару, Так теперь поиск самого важного паттерна WRB происходит на 1000 барах, поиск PPR происходит уже на 949 барах, а паттерн рельсы вообще ищется только 783 барах. И кстати говоря, функцию IsPatternWorked маленько модифицировал, но суть осталась прежней и она таки не тормазит индикатор теперь, а число обращений к ней составляет общему числу найденных паттернов, в текущем случае - 303 раза.
Отправлено: 23.02.17 21:55. Заголовок: evbut пишет: И кста..
evbut пишет:
цитата:
И кстати говоря, функцию IsPatternWorked маленько модифицировал, но суть осталась прежней и она таки не тормазит индикатор теперь, а число обращений к ней составляет общему числу найденных паттернов, в текущем случае - 303 раза.
Вы убрали цикл из этой функции? Если цикл убрать, то индикатор будет "летать"
Отправлено: 12.02.17 12:13. Заголовок: Это функция IsPatter..
цитата:
Это функция IsPatternWorked().
Познакомился с профилированием..Двойной вызов этой функции убрал. Вызовов самой функции сейчас на 1000 баров истории составляет 278, что соответствует количеству найденных паттернов. Однако вызовов iLow в ней 20650, хотя iHigh из нее же - 4951. Откуда такая разница в вызове этих строк, ведь они выполняют похожие действия и баров одинаковое количество проверяют? По логике их должно быть максимум 278 каждая...
Откуда такая разница в вызове этих строк, ведь они выполняют похожие действия и баров одинаковое количество проверяют? По логике их должно быть максимум 278 каждая...
Дело то не столько в двойном вызове функции, а в том, что она делает огромное количество повторяющихся действий. Разберем по полочкам, что же происходит. 1. Цикл i в ShowIndicatorData указывает на бар с индексом 1000. Допустим, на этом баре найден какой-то паттерн. В итоге вызывается функция IsPatternWorked(), которая запускает свой цикл от бара 1000 до бара с индексом 0. Получаем 1000 итераций сходу. 2. Цикл i в ShowIndicatorData указывает на бар с индексом 998. Допустим, на этом баре найден еще какой-то паттерн. Уже два паттерна. В итоге два раза вызывается функция IsPatternWorked(), которая запускает цикл от бара 998 до бара с индексом 0. Получаем 1996 итераций. Причем заметьте, что цикл для предыдущего найденного паттерна повторяет 998 итераций, которые были совершены на итерации цикла i = 1000 в ShowIndicatorData. 3. Цикл i в ShowIndicatorData указывает на бар с индексом 995. Допустим, на этом баре найден еще какой-то паттерн. Уже три паттерна. В итоге три раза вызывается функция IsPatternWorked(), которая запускает цикл от бара 995 до бара с индексом 0. Получаем 2985 итераций. Здесь уже два цикла лишних, т. к. эта работа уже давно выполнена. 4. Цикл i в ShowIndicatorData указывает на бар с индексом 500. Допустим, к этому моменту найдено 100 паттернов. В итоге 100 раз вызывается функция IsPatternWorked(), которая запускает цикл от бара 500 до бара с индексом 0. Получаем 500 * 100 = 50 000 итераций.
В итоге за 500 обработанных баров было совершено огромное количество лишней работы, которая и приводит к такому медленному выполнению индикатора. Чтобы уйти от такой неоптимальности, в функции IsPatternWorked() нужно избавиться от циклов. Они не нужны. Достаточно проверить отработку каждого найденного на данный момент паттерна на текущем баре (тот, который в цикле i ShowIndicatorData).
P. S. Ну а разность вызовов iLow и iHigh объясняется просто: они ведь вызываются в зависимости от типа паттерна.
Игорь, здравствуйте! Появилось желание сделать индикатор под МТ5. Судя по ошибкам, выдаваемым компилятором МТ5 главная загвоздка будет состоять в переделке в функциях нахождения паттернов, а именно всякие Low, High, Close и подобные, которых в mql5 нету... Универсальности кода по-видимому не получиться... Нужно искать аналоги... На что еще стоит обратить внимание в испытуемом коде при переносе в mql5 для корректной работы?
Игорь, здравствуйте! Появилось желание сделать индикатор под МТ5. Судя по ошибкам, выдаваемым компилятором МТ5 главная загвоздка будет состоять в переделке в функциях нахождения паттернов, а именно всякие Low, High, Close и подобные, которых в mql5 нету... Универсальности кода по-видимому не получиться... Нужно искать аналоги... На что еще стоит обратить внимание в испытуемом коде при переносе в mql5 для корректной работы?
Чтобы переходить на МТ5, сначала следует полностью отладить программу на МТ4. Без этого никак. Ну а универсальность кода для индикаторов вполне достижима (для советников - нет). Чтобы написать в стиле МТ5, используйте функции типа Copy (CopyRates, CopyHigh, CopyLow и т. д.) вместо iLow, iHigh И т. д. Правда придется немного поменять подход к их использованию, готовя данные заранее, а не беря их в том месте, где потребовались.
Не проверял синтаксис, могут быть ошибки. В целом смысл такой: передавать в функцию IsPatternWorked индекс обрабатываемого бара. И только на нем проверять отработку паттерна. Не нужно на каждом баре проверять отработку паттерна от момента его регистрации до нулевого бара. Это огромное количество лишней работы. Итогом станет многократный рост производительности индикатора.
Не работает так с имеющимся кодом - еще на начальном этапе ее конструирования она ничего не делала - как были паттерны ACTUAL, так и остаются, поскольку эта функция передает свой результат в функцию FindPatternsAndFillDB (int index)
цитата:
g_patterns[patternArray].getTarget = (IsPatternWorked(g_patterns[patternArray],index) == WORKED)? WORKED : ACTUAL;
Откуда должен передаваться индекс обрабатываемого бара?
Отправлено: 05.03.17 02:16. Заголовок: ЗДЕСЬ 14 Дней будет ..
ЗДЕСЬ 14 Дней будет лежать Крайняя версия индикатора. В ней мал-мало переделал функцию неотображения перекрывающихся паттернов, добавил опцию удаления отработанных, а также добавил еще один паттерн - Fakey.
Отправлено: 23.03.17 16:36. Заголовок: evbut пишет: ЗДЕСЬ ..
evbut пишет:
цитата:
ЗДЕСЬ 14 Дней будет лежать Крайняя версия индикатора. В ней мал-мало переделал функцию неотображения перекрывающихся паттернов, добавил опцию удаления отработанных, а также добавил еще один паттерн - Fakey.
К сожалению, меня не было здесь больше - был в отпуске. Повторите, пожалуйста.
Отправлено: 27.03.17 07:40. Заголовок: На перспективу появи..
На перспективу появилось жгучее желание сделать из него мульти кросплатформенную (MT4/MT5) версию, чтоб на желаемых инструментах из списка и на любых ТФ искал паттерны, а потом отображал в виде таблицы на подобии Этой Панели. Эх, жалко что нет исходника этой панельки - так бы можно было бы пошаманить... А поскольку там уже классы используются, то задумку придется отложить в долгий ящик, пока не пойму что это такое - классы ... Со структурой то еще шибко храмают навыки... А тут классы - дремучий лес ))) А вообще, как вы считаете будет ли достаточным в структуру struct Pattern просто добавить такие переменные как patternSymbol и patternTimeFrame, что бы бы сделать его по моему желанию? Или можно обойтись вообще без структуры -получать данные из функций типа IsBullsRailsPattern, IsBearsRailsPattern и т.д? Ведь по большому счету нужен будет лишь факт нахождения на конкретном символе, конкретного ТФ на первом баре конкретного паттерна и его таргета...
Отправлено: 28.03.17 14:47. Заголовок: evbut пишет: А вооб..
evbut пишет:
цитата:
А вообще, как вы считаете будет ли достаточным в структуру struct Pattern просто добавить такие переменные как patternSymbol и patternTimeFrame, что бы бы сделать его по моему желанию? Или можно обойтись вообще без структуры -получать данные из функций типа IsBullsRailsPattern, IsBearsRailsPattern и т.д? Ведь по большому счету нужен будет лишь факт нахождения на конкретном символе, конкретного ТФ на первом баре конкретного паттерна и его таргета...
Есть разные пути для внедрения мультимивола/мультипериода. Можно обойтись и без классов/структур в процедурном стиле. Но элегантнее код будет выглядеть для таких случаев именно в ООП. Соответственно, его отладка станет намного проще процедурного подхода.
Отправлено: 29.03.17 07:05. Заголовок: Гран мерси. Теперь м..
Гран мерси. Теперь можно и за кросс-платформенный вариант приниматься ))) а уж потом мастрить мульти-пульти версию
цитата:
Чтобы написать в стиле МТ5, используйте функции типа Copy (CopyRates, CopyHigh, CopyLow и т. д.) вместо iLow, iHigh И т. д. Правда придется немного поменять подход к их использованию, готовя данные заранее, а не беря их в том месте, где потребовались.
Тут наверно лучше использоваться CopyRates, вместо 4 других Copy... А вот в OnCalculate есть уже массивы: high, low и проч... Их Никак нельзя использовать?
PS. Попробовал прикрутить MqlRates rates[]. Прописал ее в глобальных переменных. В int GetRecalcIndex добавил строку ArrayResize(rates,0.0) - типа обнулять массив при смене таймфрейма. Затем в ShowIndicatorData прописал
цитата:
for (int i = limit; i > 0; i--) { int copied = CopyRates(NULL,0,0,i,rates); Print(copied); if (!FindPatternsAndFillDB(i)) return false;
Принт мне перечислил значения copied от 210 до 1. Но когда в OnCalculate
цитата:
int limit = GetRecalcIndex(total, rates_total, prev_calculated); //GetRecalcIndex(total); int copied = CopyRates(NULL,0,0,total,rates); Print(copied);
Принт выдает 1000. Именно такое по умолчанию стоит значение indBarsCount. Почему так? Ну и разумеется при замене Low на rates[index].low вылазит ошибка выхода за пределы массива (( Чот видать не туда шагать начал ((
Отправлено: 29.03.17 20:04. Заголовок: evbut пишет: Тут на..
evbut пишет:
цитата:
Тут наверно лучше использоваться CopyRates, вместо 4 других Copy...
Это зависит от того, какого рода информация нужна. Бывает так, что информация по всей свече не требуется.
evbut пишет:
цитата:
А вот в OnCalculate есть уже массивы: high, low и проч...
Можно. Но придется тащить их передачу практически во все используемые функции, что далеко не всегда удобно. Да и лишнее заполнение стека, к размеру которого чувствительна любая программа.
evbut пишет:
цитата:
Принт мне перечислил значения copied от 210 до 1. Но когда в OnCalculate
Если смотрели в журнале, который в закладке "Эксперты", то вполне такое может быть. Этот журнал при массовом выводе информации режет ее, чтобы не было переполнения. В таких случаях журнал нужно смотреть через контекстное меню закладки логов "Открыть". Если открыть полную версию журнала, то получим те же 1000 значений.
evbut пишет:
цитата:
Ну и разумеется при замене Low на rates[index].low вылазит ошибка выхода за пределы массива (( Чот видать не туда шагать начал ((
Имейте в виду, что нумерация баров после использования функций типа Copy изменяется на противоположную. Причем в достаточно сложном сочетании, т. к. нулевой элемент всякий раз указывает на разный бар. С этим фактом всегда ломается огромное количество копий.
Имейте в виду, что нумерация баров после использования функций типа Copy изменяется на противоположную. Причем в достаточно сложном сочетании, т. к. нулевой элемент всякий раз указывает на разный бар. С этим фактом всегда ломается огромное количество копий.
ArraySetAsSeries(rates,true) не помогает в этом случае? И как обычно борются с этой напастью?
Отправлено: 03.04.17 20:00. Заголовок: evbut пишет: Решил ..
evbut пишет:
цитата:
Решил проблему. Не знаю на сколько оправдано, тем не менее работает и в МТ4 и в МТ5. CopyRates(NULL,0,0,rates_total,rates)
Не-не, очень плохо. Зачем Вам весь массив данных, если максимум четыре бара для поиска паттерна требуется? Просто на каждом баре запрашивайте четыре последних свечи:
Имеется в виду, что nBarIndex - это текущий обрабатываемый бар (тот, который в главном цикле задается). От него, включая его, запрашивается всего 4 бара. Это достаточно быстрая операция. Если выполнение функции успешно завершено, то в элементе 0 массива stRates будут данные о баре (nBarIndex + 3), в элементе 1 - данные от (nBarIndex + 2), в элементе 2 - данные (nBarIndex + 1) и в элементе 3 - от бара nBarIndex.
P. S. Кстати, в MQL5 конструкция CopyRates(NULL, 0...) работать не будет. Обязательно требуется CopyRates(Symbol(), PERIOD_CURRENT...).
Отправлено: 04.04.17 20:54. Заголовок: evbut пишет: Без Ar..
evbut пишет:
цитата:
Без ArraySetAsSeries не отображаются паттерны, а с ним отображаются
Я же говорю - массив переворачивается. А ArraySetAsSeries переворачивает его обратно, в таймсерию. Если не хочется переписывать функции поиска паттернов, то да, нужен ArraySetAsSeries. Но в этом случае код получается не адаптированным, а именно переведенным (как Google Translate переводит с одного языка на другой) на MQL5. То есть по-хорошему для универсального кода нужно переписать функции поиска паттернов, развернув в них нумерацию баров.
evbut пишет:
цитата:
Хм... а ведь работает
Сейчас работает, но нет гарантий, что будет работать в будущем. Это недокументированная возможность, перешедшая с MQL4. Поменяют MetaQuotes значения перечислений, и тогда все подобные коды полетят в тартарары.
То есть по-хорошему для универсального кода нужно переписать функции поиска паттернов, развернув в них нумерацию баров.
Ну да... поглядел несколько кодов на MQL5 и в них наоборот пишется, т.е. если в MQL4 пишем к примеру
цитата:
if(Close[index] >= Low[index+1]) // Минимум предыдущей свечи не пробит return(false);
то в MQL5 это будет кажется вот так
цитата:
if(Close[index-1] >= Low[index]) // Минимум предыдущей свечи не пробит return(false);
Поразмыслил над вашим
цитата:
что nBarIndex - это текущий обрабатываемый бар (тот, который в главном цикле задается). От него, включая его, запрашивается всего 4 бара. Это достаточно быстрая операция. Если выполнение функции успешно завершено, то в элементе 0 массива stRates будут данные о баре (nBarIndex + 3), в элементе 1 - данные от (nBarIndex + 2), в элементе 2 - данные (nBarIndex + 1) и в элементе 3 - от бара nBarIndex.
и получается, что на каждом новом баре бар nBarIndex + 3 будет запрашиваться 1 раз, бар nBarIndex + 2 - два раза и nBarIndex + 1 - три раза... как вы говорите двойная работа и даже тройная... Или нет? Такое необходимо только 1 раз сделать при первом обращении в функцию OnCalculate, а далее записывать в массив MQLrates данные только первого бара.
Отправлено: 07.04.17 20:24. Заголовок: evbut пишет: то в M..
evbut пишет:
цитата:
то в MQL5 это будет кажется вот так
Ни в коем случае. В MQL5 другой подход к сбору данных: через функции CopyXXX. Такой же способ сбора данных имеется в MQL4. Это и дает возможность написания кроссплатформенных кодов. То есть даже в MQL4 при использовании способа получения данных через CopyXXX придется разворачивать логику.
evbut пишет:
цитата:
и получается, что на каждом новом баре бар nBarIndex + 3 будет запрашиваться 1 раз, бар nBarIndex + 2 - два раза и nBarIndex + 1 - три раза... как вы говорите двойная работа и даже тройная... Или нет? Такое необходимо только 1 раз сделать при первом обращении в функцию OnCalculate, а далее записывать в массив MQLrates данные только первого бара.
Для чего тянуть весь массив данных (если пополнять MQLRates)? Это не нужно, т. к. потребует лишнюю память. Просто на каждой итерации запрашиваются данные о 4 барах и к следующей итерации они благополучно теряются. Ведь все равно на каждой итерации необходимо делать запрос данных, хотя бы одного (нового) бара. А 1 бар будет запрошен или 4 бара - разницы практически никакой. Другое дело, если бы речь шла о тысячах баров. Тогда нужно было бы что-то придумывать.
Ну и далее в каждой функции поиска паттерна через цикл for(int i = 0; i < ArraySize(g_candles); i++) исправляем всякие Close, High и Low и проч на данные из этой структуры Не тот маршрут выбрал? )))
Пока не понял преимущество такой надстройки. В моих кодах для таких целей пока хватало стандартной структуры MqlRates. То есть вместо того, чтобы использовать стандартные таймсерии, достаточно один раз на каждой итерации цикла запросить данные о последних 4-х барах и передать эту структуру всем функциям, которые используют данные для свечей.
Отправлено: 10.04.17 06:02. Заголовок: Это понятно, что коп..
Это понятно, что копировать на каждой i данные только 4х свечей включая саму i. Не поятен мне вопрос по смене логики, чтобы и в mql4и mql5 работало без ArraySetSeries.
Отправлено: 14.04.17 19:04. Заголовок: evbut пишет: Это по..
evbut пишет:
цитата:
Это понятно, что копировать на каждой i данные только 4х свечей включая саму i. Не поятен мне вопрос по смене логики, чтобы и в mql4и mql5 работало без ArraySetSeries.
К примеру, в оригинальной версии поиск бычьего паттерна PPR выглядит так:
цитата:
bool IsBullsPPRPattern(int index) { if(Close[index] <= High[index+1]) // Максимум предыдущей свечи не пробит return(false); // Паттерн не сформирован
if (Low[index+1] >= Low[index+2] || // Минимум предыдущего бара не.. Low[index+1] >= Low[index]) // ..является минимумом паттерна return(false); // Паттерн не сформирован
if (Close[index+2] >= Open[index+2]) // Стартовый бар паттерна не является return(false); // ..медвежьим - выход*/
return(true); // Паттерн сформирован }
Здесь index - бар, находящийся по графику правее, чем бар (index + 1). Если же получен массив rates[4] при помощи CopyRates без использования ArraySetAsSeries, то функция будет выглядеть следующим образом:
цитата:
bool IsBullsPPRPattern(const MqlRates &rates[4]) { if (rates[3].close <= rates[2].high) // Максимум предыдущей свечи не пробит return(false); // Паттерн не сформирован
if (rates[2].low >= rates[1].low || // Минимум предыдущего бара не.. rates[2].low >= rates[3].low) // ..является минимумом паттерна return(false); // Паттерн не сформирован
if (rates[1].close >= rates[1].open) // Стартовый бар паттерна не является return(false); // ..медвежьим - выход*/
return(true); // Паттерн сформирован }
Здесь не используется элемент массива rates с индексом 0, т. к. это эквивалент бара (index + 3). Индекс 1 массива rates - это эквивалент бара (index + 2), элемент 2 - эквивалент (index + 1), а элемент 3 - эквивалент index. То есть все индексы "перевернуты".
Отправлено: 15.04.17 15:59. Заголовок: Вот жеж... Взрыв моз..
Вот жеж... Взрыв мозга ))) Во времена первого знакомства с форекс именно так и считал, что нумерация баров начинается с более древней даты... Долго не мог вытравить из себя такой подход... За год наверно избавлися и приучил считать в виде таймсерий... а теперь придется снова приучать себя иногда именно так и считать бары)))) Функция поиска Внутреннего бара выглядела так:
цитата:
bool IsIBPattern(int index, int total, int& patternStart) { while(IsSimpleIB(patternStart) && // Поиск элементарных паттернов подряд patternStart < total) patternStart++;
if (patternStart == index) // Ни один паттерн не найден return(false);
return(true); // Паттерн найден }
а теперь будет выглядеть вот так, если MqlRates rates[4] вынести на глобальный уровень?
цитата:
bool IsIBPattern(int total, int& patternStart) { total = ArraySize(rates)-1; for (int i = 0; i < total; i++) { while(IsSimpleIB() && // Поиск элементарных паттернов подряд patternStart < total) patternStart++;
if (patternStart == i) // Ни один паттерн не найден return(false); } return(true); // Паттерн найден }
А вообще не понятно зачем НЕ использовать ArraySetSeries? Пересмотрел кучу индикаторов в MQL5 и львиная доля её использует.
Отправлено: 20.04.17 16:18. Заголовок: evbut пишет: Вот же..
evbut пишет:
цитата:
Вот жеж... Взрыв мозга ))) Во времена первого знакомства с форекс именно так и считал, что нумерация баров начинается с более древней даты... Долго не мог вытравить из себя такой подход... За год наверно избавлися и приучил считать в виде таймсерий... а теперь придется снова приучать себя иногда именно так и считать бары))))
На самом деле это очень полезно - уметь считать и так, и эдак. Избавляет мозг от узкого понимания ситуации и лишний раз напоминает ему, что все в этом мире относительно. Кстати, в трейдинге очень помогает
evbut пишет:
цитата:
Функция поиска Внутреннего бара выглядела так: а теперь будет выглядеть вот так, если MqlRates rates[4] вынести на глобальный уровень?
Точно не так, т. к. цикл i ничего не дает для функции IsSimpleIB(). Как ей узнать, что нужно обращаться к другим барам? Или же здесь цикл i лишний, а все изменения касаются именно функции IsSimpleIB().
evbut пишет:
цитата:
А вообще не понятно зачем НЕ использовать ArraySetSeries? Пересмотрел кучу индикаторов в MQL5 и львиная доля её использует.
Львиная доля индикаторов, написанная на MQL, это очень низкий уровень написания кода. В этой сфере очень мало профессиональных программистов. Потому и подходы далеко не всегда верные. Хотя против ArraySetAsSeries() ничего не имею. Это как раз нельзя считать плохим тоном. То есть да, можно и при помощи ArraySetAsSeries работать, по старинке. Просто мне всегда казалось логичным нумеровать бары именно слева направо по истории, а не наоборот. Поэтому был рад, когда в MQL5 появилась такая нумерация. Ведь любой бар в истории отныне имеет неизменный индекс.
Пытаюсь разобраться с прямой и обратной индексацией баров и CopyRates Запрашиваю данные 4 свечей с принтом (limit = 20).
цитата:
for (int i = limit; i > 0; i--) { ratesCnt = CopyRates(_Symbol,PERIOD_CURRENT,i,4,rates); for(int j = ArraySize(rates)-1; j >=0; j--) { Print(j + " " + Time[j] + " High " + rates[j].high); }
на картинке ценовые метки проставлены по хаям баром. Вертикальная линия стоит на баре = limit и видим, что дата его 22.032017. В принтах же нет такой даты по 4-м запрашиваемым барам ни с использованием ArraySetSeries ни без него. Почему так, я не правильно запросил время бара или это какое-то недоразумение со стороны какой-то функции?
Аха... теперь затыка с границами паттернов, в частности с верхней и нижней в функции FindPatternsAndFillDB
цитата:
double lowPrice = Low[iLowest(NULL,0,MODE_LOW,// Нижняя граница паттерна startBar-endBar+1,endBar)]; double highPrice = High[iHighest(NULL,0,MODE_HIGH,// Верхняя граница паттерна startBar-endBar+1,endBar)];
С правой и левой границами сложности нет: правая всегда равна rates[0].time или rates[3].time в зависимости от установки ArraySetAsSeries. А от нее отсчитываем нужное количество баров влево в зависимости от паттерна.
Решил так сделать (ведь универсальности пытаюсь добиться)... поскольку startBar и endBar теперь у нас в виде времени, то получим индексы этих баров на графике int rightbar = iBarShift_(_Symbol,PERIOD_CURRENT,endBar,true); int leftbar = iBarShift_(_Symbol,PERIOD_CURRENT,stratBar,true);
В итоге расчет будет вестись вот так с помощью дополнительных функций, аналогов MQL4
Аха... теперь затыка с границами паттернов, в частности с верхней и нижней в функции FindPatternsAndFillDB
В данном конкретном случае лучший выход - сделать функцию перебора по барам в поисках нужного экстремума, т. к. баров предполагается немного (4 - это действительно мало):
цитата:
double GetExtremum(const MqlRates &starrRates[], int nBars, int nExtMode) { int nTotal = int(MathMin(nBars, ArraySize(starrRates))); double fExtremum = 0.0; for (int i = 0; i < nTotal; ++i) { if (nExtMode == MODE_HIGH && fExtremum < starrRates[ i ].high) fExtremum = starrRates[ i ].high;
if (nExtMode == MODE_LOW && (fExtremum == 0.0 || fExtremum > starrRates[ i ].low)) fExtremum = starrRates[ i ].low; }
Понятно. Но, чтобы их получить, нужно будет использовать искусственную функцию перевода времени бара в индекс?
patternsBars - это количество, а не индекс. Поэтому ничего получать не нужно. Вместо patternsBars подставляется 2, 3 или 4 в зависимости от типа паттерна.
evbut пишет:
цитата:
В MQL5 нету iBarShift.
Зато есть замечательная функция Bars, которая с лихвой покрывает возможности iBarShift от MQL4. Смотрите второй вариант функции:
цитата:
int Bars( string symbol_name, // имя символа ENUM_TIMEFRAMES timeframe, // период datetime start_time, // с какой даты datetime stop_time // по какую дату );
Если использовать ее следующим образом:
цитата:
int nBarIndex = Bars(Symbol(), Period(), time, TimeCurrent());
то получим аналог iBarShift(). Единственный момент - могут быть смещения в +/-1 бар, если time попадает не на время открытия бара.
int i_BarShift(datetime time) { return (Bars(_Symbol, PERIOD_CURRENT, time, TimeCurrent())-1); }
Scriptong пишет:
цитата:
Единственный момент - могут быть смещения в +/-1 бар, если time попадает не на время открытия бара.
Смещение на +1 бар как бы очевидное получается ведь в счет идет и текущий, так называемый "нулевой" бар. А в каких случаях и как часто бывает смещение на -1 бар? Как-то контролировать можно этот момент?
Смещение на +1 бар как бы очевидное получается ведь в счет идет и текущий, так называемый "нулевой" бар.
В принципе, если нужно считать ровно так же, как и в MQL4, то лучше все-таки начинать поиск со времени на 1 секунду ранее, чем нулевой бар:
цитата:
datetime dtTime0Bar[]; CopyTime(Symbol(), PERIOD_CURRENT, 0, 1, dtTime0Bar); int nBarIndex = Bars(Symbol(), PERIOD_CURRENT, time, dtTime0Bar[0] - 1)
Это позволит не включать в интервал поиска нулевой бар, индекс которого при счете справа налево нам всегда известен.
evbut пишет:
цитата:
А в каких случаях и как часто бывает смещение на -1 бар?
Когда третий и четвертый аргумент указывают на время внутри одного и того же бара, к примеру. В документации (см. примечание) этот момент специально описан. Также возможен случай, когда третий аргумент указывает на время правее одного бара, который предполагается включить в расчет, а четвертый - чуть левее. Так и получим -1 от того значения, которое вернула бы функция iBarShift(). Она ведь работает несколько по-другому - использует округление к ближайшему бару.
evbut пишет:
цитата:
Как-то контролировать можно этот момент?
Сравнить время открытия полученного бара со временем, указанным в третьем аргументе. Если данные равны, то все ОК, если нет, то вычесть или добавить 1. Это уже зависит от поставленной задачи.
Отправлено: 12.05.17 09:18. Заголовок: День добрый! Начал ..
День добрый! Начал по-тихоньку продумывать логику мульти-пульти варианта. Хочется узнать ваше мнение о, так сказать, правильности и локоничности хода моих мыслей. В общем, чтобы находить тот или иной паттерн на разных символах и таймфреймах задумал создать главную (определяющую) структуру по символу(список символов), в состав которой входят данные с таймфреймов (список периодов и данные типа MqlRates для каждого периода):
Таким образом, чтобы получить данные на каждой свече последних 3 свечей будет вызваться CopyRates() в тройном цикле:
цитата:
for (int k = limit; k > 0; k--) интерации по барам for (int i = 0; i < ArraySize(g_symbdata); i++) интерации по символам for (int j = 0; j < ArraySize(g_tfInfo); j++) интерации по периодам { if(!CopyRates(g_symbdata.symbol,g_symbdata.g_tfInfo[j].tf,k,3,g_symbdata.g_tfInfo[j]._symbol)) return false; }
Проверку корректности получаемых данных провожу далее принтом:
цитата:
for(int x = ArraySize(g_symbdata.g_tfInfo[j]._symbol)-1; x >=0; x--) { double high = g_symbdata.g_tfInfo[j]._symbol[x].high; double low = g_symbdata.g_tfInfo[j]._symbol[x].low; datetime time = g_symbdata.g_tfInfo[j]._symbol[x].time;
Print(g_symbdata.symbol + " Period [" + g_symbdata.g_tfInfo[j].text+ "] Bar from rates [" + IntegerToString(x) + "][" + TimeToStr(time) + "] High = [" + high + "] Low = [" + low + "] Time = [" + TimeToStr (time, TIME_DATE|TIME_SECONDS) + "]");
Анализ данных с принта и по графикам каждого символа и таймфрейма получается, что все необходимые данные для определения того же паттерна ППР у нас записаны в структуре. Выходит далее к примеру в функции поиска бычьего паттерна ППР (IsBullsPPRPattern()) будет выглядеть так:
цитата:
bool IsBullsPPRPattern(int index) { for (int i = 0; i < ArraySize(g_symbdata); i++) for (int j = 0; j < ArraySize(g_tfInfo); j++) for(int x = 0; x < ArraySize(g_symbdata.g_tfInfo[j]._symbol); x++) { if(g_symbdata.g_tfInfo[j]._symbol[0].close <= g_symbdata.g_tfInfo[j]._symbol[1].high) // Максимум предыдущей свечи не пробит return(false); // Паттерн не сформирован
if (g_symbdata.g_tfInfo[j]._symbol[1].low >= g_symbdata.g_tfInfo[j]._symbol[2].low || // Минимум предыдущего бара не.. g_symbdata.g_tfInfo[j]._symbol[1].low >= g_symbdata.g_tfInfo[j]._symbol[0].low) // ..является минимумом паттерна return(false); // Паттерн не сформирован
if (g_symbdata.g_tfInfo[j]._symbol[2].close >= g_symbdata.g_tfInfo[j]._symbol[2].open) // Стартовый бар паттерна не является return(false); // ..медвежьим - выход*/ }
return(true); // Паттерн сформирован }
Что скажите? Громоздко по-моему все получается... Для каждой функции поиска паттерна тройные циклы. Это все же пока набросок. Вызов функций разумеется в дальнейшем будет происходить не в OnCalculate, а через OnTimer... Файл черновика ПРИЛАГАЕТСЯ
Отправлено: 16.05.17 18:18. Заголовок: Все намного проще. У..
Все намного проще. У Вас уже имеется код для работы с одним символом. Далее требуется вызывать его точно также, но с одним фиксом: передать в него имя символа. Так, на сегодня имеется функция ShowIndicatorData. Она работает с текущим символом. Чтобы сделать ее универсальной, требуется всего лишь передать ей имя символа, с которым необходимо работать. И далее внутри этой функции передать имя символа подчиненным функциям:
цитата:
bool ShowIndicatorData(string strSymbol, int limit) { for (int i = limit; i > 0; i--) { if (!FindPatternsAndFillDB(strSymbol, i)) return false;
if (ShowWorkedPattern == NO) continue;
ProcessSLAndTPOfPatterns(strSymbol, i); }
return true; }
В итоге для расчета паттернов по нескольким символам потребуется всего лишь один цикл:
цитата:
for (int i = ArraySize(g_symbdata) - 1; i >= 0 ; --i) // итерации по символам ShowIndicatorData(g_symbdata[ i ], limit);
Правда в данном случае еще нужно для каждого символа рассчитать свое значение limit.
Кстати, поставленная задача (мультивалютный индикатор) как нельзя лучше решается через ООП. Ведь в данном случае достаточно взять готовый код, сделать из него класс, а уже класс тиражировать для разных символов. Таким образом, отпадает даже необходимость в индивидуальном расчете значения limit, т. к. это уже есть в коде.
Все даты в формате GMT
2 час. Хитов сегодня: 0
Права: смайлы да, картинки да, шрифты да, голосования нет
аватары да, автозамена ссылок вкл, премодерация откл, правка нет
Может в коде какого дополнительного условия не хватает в функции IsActualPattern? Или это не понятные примудрусти какие-то в функции строки подписи? 
Можно и так. В итоге приоритет поиска паттернов в данном случае получается следующий: 
- участник сейчас на форуме