Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Один вариант. Есть и другие.
Имеем первый луч. Для простоты - идущий от нулевого бара. Нулевой бар имеет максимум и минимум. Цена ходит внутри бара, не меняя его экстремумы. Раз экстремумы не меняются, то и первый луч должен стоять на месте и не двигаться. Но не тут то было. Первый луч дергается. Меняет свое положение. Это просто описание внешнего проявления неустойчивости. Если алгоритм работает стабильно, параметры рынка (максимум и минимум последнего бара), от которых зависит работа зигзага, не меняются, то и первый луч не должен дергаться. Боролся с этой проблемой самостоятельно. Но замеченные особенности работы функций поиска заставили выйти на форум.
========================
Когда мы в процессе расчёта индикатора двигаем окно (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)
Но не тут то было. Первый луч дергается. Меняет свое положение.
Я пока такого не видел. Остаётся ли при этом один конец луча закреплённым? И какой именно. Если на нулевом баре, то может быть стоит присмотреться к условиям, где сравниваются переменные типа double?
Мне кажется, это относится не к языку, а к алгоритму. То есть напоминание о том, что обсуждаемые функции ищут на самом деле не экстремум, а максимальное(минимальное) значение цены на интервале, уместнее в книге или в каких-нибудь комментариях.
пункт 4) на следующем тике обрабатывается напильником через пункт 2)
Эта проблема известна, и теоретически фиксится (в голове алгоритм есть давно).
Дело в том, что я тестирую индикатор, использующий зигзаг, в очень жестких условиях. На минутках и с параметрами 2-1-1. Для чего такое тестирование? Такое тестирование проявляет все скрытые недостатки достаточно быстро. Плюс к этому - есть желание, чтобы индикатор работал на всех таймфреймах без исключения. Рынок штука фрактальная. Есть много людей, кто торгует на минутках. Зачем их лишать возможности работы с привычным инструментом на мелких таймфреймах?
Мой вариант мне нравится больше :). Он работает с целыми. При таком сравнении double (типа Low[shift]==val) как раз и могут появляться биения.
Работа с double пока не вызывала трудностей. В памяти эти числа хранятся без изменения. А мое сравнение берет значения из одной ячейки памяти. Если будет в этом месте появляться проблема, то это уже вопрос к железу - компьютеру. Что-то с железом надо делать.
Мне кажется, это относится не к языку, а к алгоритму. То есть напоминание о том, что обсуждаемые функции ищут на самим деле не экстремум, а максимальное(минимальное) значение цены на интервале, уместнее в книге или в каких-нибудь комментариях.
Я просто так назвал - экстремум. На самом деле наибольший максимум и наименьший минимум на выбранном участке. Это долго произносить. А смысл тот же.
Было долгое время на сайте CodeBase.mql4.com. Но то описание очень сложное для понимания. И противоречивое. Летом, кажется, Слава подрихтовал код зигзага. На сайте после этого остаили только часть прежнего описания.
Работа с double пока не вызывала трудностей. В памяти эти числа хранятся без изменения. А мое сравнение берет значения из одной ячейки памяти. Если будет в этом месте появляться проблема, то это уже вопрос к железу - компьютеру. Что-то с железом надо делать.