Не исключено, что я что-то неправильно сделал, но после встраивания в индикатор как-то вот так получается (GetNextHighest, GetNextLowest встроены без изменений, вызов их - приспособлен к переменным из индикатора):
Max = GetNextHighest(-limit, P);
Min = GetNextLowest(-limit, P);
for (int i=limit; i>0; i--)
{
...
Max = GetNextHighest(i, P);
Min = GetNextLowest(i, P);
...
}
Специально привел исходник скрипта, исключающий желание измерения перформанса кривой встройки в индикатор. Замеряйте скрипт, а пряморукая встройка в индикатор - другая тема. Мне неведомо, что и как вы делали.
Алгоритм привел, скорость в разы и порядки выше "классики". Но даже PriceChannel-индикатор написан "классически"-тормознуто: без желания хоть немного думать.
ЗЫ Посмотрите, как меняется разница скоростей, в зависимости от величины периода P.
Я там дописать не успел, отвлекли от компьютера. А вот для Р=1000 (большее значение врядли буду использовать):
Max = GetNextHighest(-limit, P);
Min = GetNextLowest(-limit, P);
for (int i=limit; i>0; i--)
{
...
Max = GetNextHighest(i, P);
Min = GetNextLowest(i, P);
...
}
А насчёт того, что большинство кода в кодобазе написано тормознуто и
стандартно, так это легко обьясняется шаблонностью мышления большинства
писателей, как в примерах видим - так и пишем, чего уж там.
Работает
алгоритм как задумывалось - мы и радуемся, а что медленно, так что
поделать, у всех так )))
И совсем мало тех, кто укажет, что и как надо поменять, или в какую сторону копать, чтобы и работало как задумали, и быстро ещё.
evillive: В моём случае, для каждого значения i в цикле надо найти макс. Хай и мин. Лоу среди Р баров.
А Вы просто попробуйте. Это же не долго ?
ЗЫ. Навскидку - результат должен быть идентичен, если не ошибаюсь.
А нет - возможны варианты - нужно предусмотреть еще один момент. Ща подумаю
ЗЗЫ В предыдущем коде возможны сюрпризы: если предыдущий экстремум не будет пробит на расстоянии большем, чем период P от текущего бара, то Вы не получите желаемого результата - останется старый экстремум. В этом случае нужен пересчет. Поправленный код получается аналогичным тому, что привел lob32371 , разве что без вызова функций :
int iMx = iHighest(NULL, 0, MODE_HIGH, P, Limit),
iMn = iLowest( NULL, 0, MODE_LOW , P, Limit);
double Max = High[iMx],
Min = Low[ iMn];
for (int i = Limit; i >= 0; i--)
{
// ...double dMx = High[i];
double dMn = Low[i];
if(iMx-i<P)
{
if(dMx>=Max)
{
Max = dMx;
iMx = i;
}
}
else
{
iMx = iHighest(NULL, 0, MODE_HIGH, P, i);
Max = High[iMx];
}
if(iMn-i<P)
{
if(dMn<=Min)
{
Min = dMn;
iMn = i;
}
}
else
{
iMn = iLowest( NULL, 0, MODE_LOW , P, i);
Min = Low[iMn];
}
// ...
}
ЗЫ. Навскидку - результат должен быть идентичен, если не ошибаюсь.
Не совсем совпадают результаты, при наложении обоих вариантов с теми же параметрами видны отличия. Вариант lob32371 по результату совпадает с оригиналом.
Бледные крупные стрелки - оригинал, мелкие - ваш вариант.
Замеряйте:
Не исключено, что я что-то неправильно сделал, но после встраивания в индикатор как-то вот так получается (GetNextHighest, GetNextLowest встроены без изменений, вызов их - приспособлен к переменным из индикатора):
Специально привел исходник скрипта, исключающий желание измерения перформанса кривой встройки в индикатор. Замеряйте скрипт, а пряморукая встройка в индикатор - другая тема. Мне неведомо, что и как вы делали.
Алгоритм привел, скорость в разы и порядки выше "классики". Но даже PriceChannel-индикатор написан "классически"-тормознуто: без желания хоть немного думать.
ЗЫ Посмотрите, как меняется разница скоростей, в зависимости от величины периода P.
Я смотрел, в скрипте и правда разница впечатляющая, но мне больше интересен практический аспект применения в индикаторе, а не абстрактный скрипт.
Учитывая, что остальной код индикатора не менялся, улучшения быстродействия добиться не сумел.
Да, забыл сказать, для тестов выше Р=1.
Да, забыл сказать, для тестов выше Р=1.
У вас тонкое чувство юмора... Для такого периода вообще ничего вычислять не требуется.
Я там дописать не успел, отвлекли от компьютера. А вот для Р=1000 (большее значение врядли буду использовать):
То есть вы правы, хоть код и разбух немного, но такой подход намного быстрее традиционных. Мне это никогда бы в голову не пришло, спасибо.
А насчёт того, что большинство кода в кодобазе написано тормознуто и стандартно, так это легко обьясняется шаблонностью мышления большинства писателей, как в примерах видим - так и пишем, чего уж там.
Работает алгоритм как задумывалось - мы и радуемся, а что медленно, так что поделать, у всех так )))
И совсем мало тех, кто укажет, что и как надо поменять, или в какую сторону копать, чтобы и работало как задумали, и быстро ещё.Для Вашего случая, если правильно понял то, что Вам нужно, попробуйте так:
Для Вашего случая, если правильно понял, попробуйте так:
В моём случае, для каждого значения i в цикле надо найти макс. Хай и мин. Лоу среди Р баров. Хотя ваш код тоже работоспособен, как мне кажется.
В моём случае, для каждого значения i в цикле надо найти макс. Хай и мин. Лоу среди Р баров.
А Вы просто попробуйте. Это же не долго ?
ЗЫ. Навскидку - результат должен быть идентичен, если не ошибаюсь.
А нет - возможны варианты - нужно предусмотреть еще один момент. Ща подумаю
ЗЗЫ В предыдущем коде возможны сюрпризы: если предыдущий экстремум не будет пробит на расстоянии большем, чем период P от текущего бара, то Вы не получите желаемого результата - останется старый экстремум. В этом случае нужен пересчет. Поправленный код получается аналогичным тому, что привел lob32371 , разве что без вызова функций :
А Вы просто попробуйте. Это же не долго ?
ЗЫ. Навскидку - результат должен быть идентичен, если не ошибаюсь.
Не совсем совпадают результаты, при наложении обоих вариантов с теми же параметрами видны отличия. Вариант lob32371 по результату совпадает с оригиналом.
Бледные крупные стрелки - оригинал, мелкие - ваш вариант.