торговая стратегия на базе Волновой теории Эллиота - страница 273

 

Расчет Херста на выборку в 3000 баров в MQL4 у меня занимал порядка 40 миллисекунд. Скорей всего мы под этим подразумеваем разные понятия (слово расчет),поэтому, если можете, сбросьте мне в общих словах алгоритм Вашего расчета (желательно) или код в MathCad'е в крайнем случае (при необходимости влезу и в Маткад).

Что то не так с расчетами в любом случае. Мой мейл rosh AT metaquotes DOT ru.


Я наверно опять не очень корректно выразил свою мысль. Я имел в виду не одна выборка – 600 отсчетов считается 20 минут. Грубо говоря 500 итераций, т.е. первая выборка, для мертвой зоны [0; 100], вторая [0; 101], далее [0; 102], [0; 103]…. [0; 600]. К тому же, это MathCAD, а продукты этого класса не самые лучшие с точки зрения оптимальных вычислений. Серьезную оптимизацию разработчики ввели только в 13 версии, которую, я и использую. До этого, даже численное решение какого ни будь простого уравнения, могло занять продолжительное время.

Расчет показателя у меня несколько иной, чем можно найти в доступных источниках, при этом я не отступаю от идеологии классического Херста. Другими словами, не могу сказать, что рассчитываю статистику имени grasn. :о) Сам же алгоритм написан оптимально, проверено и перепроверено.

PS: Огромное спасибо за готовность помочь. Очень даже возможно, что она понадобиться. Поделюсь алгоритмом, если в ближайшее время удастся реализовать более совершенный механизм. Есть пара идей.
 

Расчет Херста на выборку в 3000 баров в MQL4 у меня занимал порядка 40 миллисекунд. Скорей всего мы под этим подразумеваем разные понятия (слово расчет),поэтому, если можете, сбросьте мне в общих словах алгоритм Вашего расчета (желательно) или код в MathCad'е в крайнем случае (при необходимости влезу и в Маткад).


Алгоритмов довольно много. Нашел в своем архиве расчет спектра сингулярности. Описан концептуально во многих книгах, например у Федера, Божокина и многих других. Итераций для одной выборки довольно приличное количество. В частности, для оценки вносимого каждым интервалом «движения» выполняется итерационный процесс возведения в степень, выявляя различные типы поведения сигналов (например, «сейчас» больший «вклад» вносят интервалы с большими отклонениями от тренда и т.д.).

Все это можно прочитать, но напомню основную характеристику, - величина alpha, при которой F(alpha) достигает максимума и есть обобщенный показатель Херста (иногда, скайлинговый параметр)


Расчет для выборки в 500 отсчетов. Обобщенный показатель Херста равен 0.6.


А вот сам ряд (до вертикальной красной линии) для которого был выполнен расчет и то, что случилось позже.



В «дело» так и не пошел (хотя весьма интересная штука), потому, как пока не выяснил некоторые моменты, а именно способ удаления локальных трендов. При разных способах, получаются разные характеристики ряда. Еще одна особенность – требует приличных выборок.

to Rosh, solandr

У меня вопрос на перспективу. Беспокоит тот факт, что эксперт будет «в отключке» на объективно продолжительное время, а следовательно, не будет заниматься контролем процесса по текущем ордерам. Полагаю, что вызов скрипта так же не поможет – эксперт будет ждать пока не выполнится скрипт. Вот я и подумал, а если ввести внешнюю (или глобальную, какую лучше?) переменную, например:

extern string SIGNAL_FORECAST



Получив сигнал, что по каким то причинам прогноза нет, эксперт выставляет соответствующее значение этого параметра с требованием на выполнение. В это время, какой ни будь индикатор (ничего особо не рисует, но содержит функции расчета) все время считывает эту переменную. Как только получает приказ на выполнение прогноза, инициализирует вычисления, но до этого пишет в переменную «расчет запущен». После выполнения «расчет выполнен». Эксперт прочитав, что расчет выполнен ….

Все это будет работать? Т.е. эксперт теоретически освободиться от бремени все рассчитывать?

 
Привет, Сергей. Мне кажется лучше всего это сделать в виде связки эксперт+эксперт или эксперт+скрипт. Второй вариант, думаю, предпочтительнее.
Эксперт занимается расчетами и при получении сигнала записывает в набор глобальных переменных флаг сигнала и соответствующие параметры. Скрипт открывает ордера согласно полученным инструкциям и занимается их сопровождением. Скрипт работает в бесконечном цикле самостоятельно изменяя частоту этого цикла в зависимости от ситуации. Эксперт, понятное дело, запускается после завершения расчетов, по приходу тика.

Индикатор здесь не подходит, так как (насколько я знаю) его вычисления прерываются по приходу нового тика.

Во всяком случае я для себя решил придерживаться именно такой схемы.
 
Эксперты, скрипты и индикаторы рассчитываются в МТ4 параллельно, то есть одновременно с соответствующим делением между собою доступных ресурсов процессора. Вы можете организовать 2 эксперта, один из которых будет по несколько часов производить расчёт, а другой будет являться исполнительным, который через глобальные переменные терминала будет получать результаты предыдущего цикла расчётов первого эксперта и производить необходимые торговые операции. Оба эксперта будут работать независимо (в плане исполнения) друг от друга. Первый расчётный эксперт у вас запустится на несколько часов при приходе первого тика, а второй будет запускаться к примеру на каждом новом пришедшем тике, или например с заданным периодом (в случае организации бесконечного цикла с требуемой паузой).
 
Привет, Сергей. Мне кажется лучше всего это сделать в виде связки эксперт+эксперт или эксперт+скрипт. Второй вариант, думаю, предпочтительнее.

Во втором варианте существует неудобство с тем что при каждом следующем запуске терминала прийдётся этот самый скрипт ручками кидать на чарт. Это очень быстро надоест. Лучше использовать первый вариант. Там с тем же самым успехом в функции start() можно организовать точно такой же бесконечный цикл что и в скрипте.
 
to Yurixx, solandr

Огромное спасибо за консультацию. Уже давно не работаю с MT, пока вел исследования и напрочь забыл о том, что скрипты можно запустить в цикле, а о двух экспертах даже и мыслей не возникло.

Но с другой стороны на такую астролябию тестер уже не напустишь? Хотя, это наверное и не столь принципиально.

Еще раз спасибо. :о)))
 
А если из индикатора запустить скрипт? В этом случае новые поступления данных в индикатор все равно прервут вычисления?
 
2 grasn:
Всё же у Вас слишком большое время расчёта. Думаю в такой ситуации лучше делать их вне МТ (всё таки Си в 17 раз быстрее MQL4 ). Не знаю, может ли Matcad генерировать сишный код, но это было бы весьма кстати. Результат писать в файл, а из эксперта этот файл читать. Этот файл может быть как бы пошаговой инструкцией для эксперта (Вообще передача данных в МТ меня до сих пор мало интересовала, возможно есть и другие способы). Записав "инструкцию" для какого-то интервала истории, Вы сможете воспользоваться и тестером. А вот потянет ли тестер связку эксперт+эксперт или эксперт+скрипт? Подозреваю, что нет.
 
Кстати, насколько я понимаю, сейчас вычисления не прерываются. Они выполняются для значений данных, имевших место на начало расчёта, после этого терминал делает скачок к свежим данным.
 
to Candid

2 grasn:
Всё же у Вас слишком большое время расчёта. Думаю в такой ситуации лучше делать их вне МТ (всё таки Си в 17 раз быстрее MQL4 ). Не знаю, может ли Matcad генерировать сишный код, но это было бы весьма кстати. Результат писать в файл, а из эксперта этот файл читать. Этот файл может быть как бы пошаговой инструкцией для эксперта (Вообще передача данных в МТ меня до сих пор мало интересовала, возможно есть и другие способы). Записав "инструкцию" для какого-то интервала истории, Вы сможете воспользоваться и тестером. А вот потянет ли тестер связку эксперт+эксперт или эксперт+скрипт? Подозреваю, что нет.


Это верно, время расчета довольно продолжительное, буду с этим разбираться. MathCAD генерировать сишный код не умеет, но умеет это делать MathLab (если не врут конечно :о) Тестирование в MT нужно для получения более менее обоснованных с точки зрения торговли результатов (а не многочисленных тестов прогноза в MathCADе, хотя и положительных). После тестирования в MT буду думать чего делать дальше, в том числе и переносить вычисления на отдельный сервер, о чем ранее писал. Но это как у альпинистов, чем больше узлов на веревке, тем хуже.