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

 
Candid, попробую описать неустойчивость работы .

Один вариант. Есть и другие.
Имеем первый луч. Для простоты - идущий от нулевого бара. Нулевой бар имеет максимум и минимум. Цена ходит внутри бара, не меняя его экстремумы. Раз экстремумы не меняются, то и первый луч должен стоять на месте и не двигаться. Но не тут то было. Первый луч дергается. Меняет свое положение. Это просто описание внешнего проявления неустойчивости. Если алгоритм работает стабильно, параметры рынка (максимум и минимум последнего бара), от которых зависит работа зигзага, не меняются, то и первый луч не должен дергаться. Боролся с этой проблемой самостоятельно. Но замеченные особенности работы функций поиска заставили выйти на форум.
========================
Когда мы в процессе расчёта индикатора двигаем окно (shift,shift+ExtDepth), появление нового экстремума может быть связано как с новой ценой, так и с тем, что из окна ушёл старый экстремум. - хорошо бы это прописать однозначно. Чтобы было понятно. В описании языка. Чтобы не исследовать скрытые возможности языка.

Для этого в моей вставке введена строка if(highpos!=shift) val=0.0; . Как это делается в стандартном коде, я не понял. Судя по тому, что висячие экстремумы в моём варианте пропали, это делается либо неправильно, либо совсем не делается. - у меня этот момент решен по другому: if (High[shift]==val) ZigZagBuffer[shift]=val; и if (Low[shift]==val) ZigZagBuffer[shift]=val;
Но по смыслу - это одно и тоже. Но это не решает всех проблем. Мы таким образом боремся со следствием, а не с причиной. Пытался таким же образом бороться со следствием. Но на первом луче это не проходит. Дело в том, что алгоритм зигзага, скажем так, не расчленяется. Поясню это. Просчет проводится по всей истории. И если мы в какой-то части исправим ошибки, то в районе нулевого бара процесс обработки остается, скажем так, незавершенным. Затрудняюсь подобрать правильные слова. Так вот эта незавершенность в районе нулевого бара и вытаскивает на свет проблему правильного поиска экстремумов.

Пытался подбирать параметры окна (shift,shift+ExtDepth) не так давно. На днях также экспериментировал с окном. Но пока что без результата.
 
Дело в том, что алгоритм зигзага, скажем так, не расчленяется. Поясню это. Просчет проводится по всей истории. И если мы в какой-то части исправим ошибки, то в районе нулевого бара процесс обработки остается, скажем так, незавершенным. Затрудняюсь подобрать правильные слова. Так вот эта незавершенность в районе нулевого бара и вытаскивает на свет проблему правильного поиска экстремумов.


Эта проблема известна, и теоретически фиксится (в голове алгоритм есть давно). В любом случае , если не появится другое решение, я алгоритм Зигзага оптимизирую. Это делается так:
1) делается первый прогон на всей истории как в текущем алгоритме
2) на каждом тике от нулевого бара вглубь истории ищется два экстремума Зигзага, последний экстремум принудительно убивается.
3) от предспоследнего (теперь уже последнего) опять проводится стандартная процедура обсчета Зигзага.
4) если текущий конец (хвост Зигзага) теоретически может быть экстремумом (имеем самый высовки Хай от последнего Лоу или наоброт) - то он также становится Экстремумом.
5) с новым тиком все сначала с пункта 2)
 
nen:
Но не тут то было. Первый луч дергается. Меняет свое положение.

Я пока такого не видел. Остаётся ли при этом один конец луча закреплённым? И какой именно. Если на нулевом баре, то может быть стоит присмотреться к условиям, где сравниваются переменные типа double?

Когда мы в процессе расчёта индикатора двигаем окно (shift,shift+ExtDepth), появление нового экстремума может быть связано как с новой ценой, так и с тем, что из окна ушёл старый экстремум. - хорошо бы это прописать однозначно. Чтобы было понятно. В описании языка.

Мне кажется, это относится не к языку, а к алгоритму. То есть напоминание о том, что обсуждаемые функции ищут на самом деле не экстремум, а максимальное(минимальное) значение цены на интервале, уместнее в книге или в каких-нибудь комментариях.
Для этого в моей вставке введена строка if(highpos!=shift) val=0.0; . Как это делается в стандартном коде, я не понял. Судя по тому, что висячие экстремумы в моём варианте пропали, это делается либо неправильно, либо совсем не делается. - у меня этот момент решен по другому: if (High[shift]==val) ZigZagBuffer[shift]=val; и if (Low[shift]==val) ZigZagBuffer[shift]=val;
Мой вариант мне нравится больше :). Он работает с целыми. При таком сравнении double (типа Low[shift]==val) как раз и могут появляться биения.
 
Rosh, у меня такой же вариант есть. В голове. От реализации останавливают некоторые смутные моменты. Скажем так. Пункт 4) несколько выбивается из алгоритма. Это уже другой алгоритм. И, когда участок, обработанный по пункту 4), станет достоянием истории, то обработка его алгоритмом начиная с пункта 1) может нарисовать другие экстремумы. То есть реалтайм и история будут отличаться. Это, я считаю, не допустимо.
 
Rosh, у меня такой же вариант есть. В голове. От реализации останавливают некоторые смутные моменты. Скажем так. Пункт 4) несколько выбивается из алгоритма. Это уже другой алгоритм. И, когда участок, обработанный по пункту 4), станет достоянием истории, то обработка его алгоритмом начиная с пункта 1) может нарисовать другие экстремумы. То есть реалтайм и история будут отличаться. Это, я считаю, не допустимо.


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


Эта проблема известна, и теоретически фиксится (в голове алгоритм есть давно).
А существует словесное описание того, что должен делать зигзаг? Что-то вроде техзадания.
 
Я пока такого не видел. Остаётся ли при этом один конец луча закреплённым? И какой именно. Если на нулевом баре, то может быть стоит присмотреться к условиям, где сравниваются переменные типа double?
Дело в том, что я тестирую индикатор, использующий зигзаг, в очень жестких условиях. На минутках и с параметрами 2-1-1. Для чего такое тестирование? Такое тестирование проявляет все скрытые недостатки достаточно быстро. Плюс к этому - есть желание, чтобы индикатор работал на всех таймфреймах без исключения. Рынок штука фрактальная. Есть много людей, кто торгует на минутках. Зачем их лишать возможности работы с привычным инструментом на мелких таймфреймах?

Мой вариант мне нравится больше :). Он работает с целыми. При таком сравнении double (типа Low[shift]==val) как раз и могут появляться биения.
Работа с double пока не вызывала трудностей. В памяти эти числа хранятся без изменения. А мое сравнение берет значения из одной ячейки памяти. Если будет в этом месте появляться проблема, то это уже вопрос к железу - компьютеру. Что-то с железом надо делать.

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

Я просто так назвал - экстремум. На самом деле наибольший максимум и наименьший минимум на выбранном участке. Это долго произносить. А смысл тот же.
 
А существует словесное описание того, что должен делать зигзаг? Что вроде техзадания?
Было долгое время на сайте CodeBase.mql4.com. Но то описание очень сложное для понимания. И противоречивое. Летом, кажется, Слава подрихтовал код зигзага. На сайте после этого остаили только часть прежнего описания.
 
nen:
Работа с double пока не вызывала трудностей. В памяти эти числа хранятся без изменения. А мое сравнение берет значения из одной ячейки памяти. Если будет в этом месте появляться проблема, то это уже вопрос к железу - компьютеру. Что-то с железом надо делать.
Ну я исхожу из кода в ветке. А в нём val каждый раз вычисляется. Да и просто безопаснее не использовать == при сравнении double
 
Ну я исхожу из кода в ветке. А в нём val каждый раз вычисляется. Правильно, вычисляется. Находится номер ячейки. Из этой ячейки (таймсерии) берется значение максимума или минимума бара. Считается, что на этом баре был найден, допустим, максимум. Это значение потом помещается в индикаторный буфер с найденным номером. Максимум индикатора должен соответствовать максимуму на баре. И в моем коде также из массива (таймсерии) с этим же найденный номером берется максимум и сравнивается со значением val. Проверяется: правильно ли мы делаем, что помещаем в буфер с этим номером число val. Оно же должно быть равно максимуму бара. Сравнение чисел, взятых из одного и того же места, вполне корректно.
Причина обращения: