Автоматизация поиска стратегий. - страница 3

Новый комментарий
 
Aliaksandr Hryshyn:

Мелочей действительно много.

Стараюсь делать универсальную систему, чтобы с минимальными усилиями можно было добавлять разные возможности анализа индикаторов, свечей и др. Каждая функция имеет информацию, с какими данными может работать,и какие данные будут на выходе. Индикаторы тоже будут описываться, какого рода данные они предоставляют. Данные разделяются на типы как простые так и сложные, например {double} и {int,double}. Разделяются на категории, для того же примера "цена" и "позиции на графике", ещё пример:"прямая"(можно использовать для определения каналов) и т.п. Разделяются по "типу шкалы", например "константа"(параметр стратегии), "индекс"(есть минимум и максимум), "отношение"(есть только одна точка отсчёта, например цена, объём) и т.д. Необходимо непротиворечиво модифицировать стратегию, тут такой нюанс возникает, модификация в одном месте может влиять на условия модификации в другом месте.

Верно вы всё говорите... Для уменьшения количества комбинаций перебора и используются выше изложенные ограничения(тип, шкала, категория), пока достаточно будет и точечных изменений(добавление/удаления одной/несколько функций).

"рекомбинация  тоже спонтанная , но уже  целых готовых решений" - приходила данная мысль), сложно представить, как это всё можно реализовать. У группы объединённых функций связей с "внешним миром" скорее всего будет больше чем в одной функции, поэтому возможностей вклинить это всё будет меньше. Алгоритм сильно усложняется, оставим до лучших времён)).

Давайте я уточню мысль. Чтобы снизить количество  вариантов и модификация в одном не затрагивала другой блоки должны быть ЕЩЕ более  универсальные.  Фокус в том, что одни и те же задачи можно достигнуть достаточно разными методами и часто заранее непонятно какой из них лучше. К примеру мы определили некую универсальную задачу под названием ПЕРЕПРОДАННОСТЬ. Существует около десятка осциляторов, которые каждый по-своему эту перепроданность определяет. Предположим, в сценарий генератора мы заложили задачу попробовать ВСЕ индикаторы или все способы. Тогда мы должны стандартизировать взаимодействие этих блоков с остальным кодом. Скажем, мы выбрали стандарт взаимодействия - проценты от верха. Генератор последовательно просто вставляет в код блок-заготовку под название Перепроданность1, обнаруживает переменные, которые нужно протестировать в данном конкретном блоке, прогоняет волкин-форвард и запоминает результаты тестирования. Затем он готовит новую версию советника, уже с блоком Перепроданность 2 который тоже выдает проценты, несмотря на то, что исходный индикатор показывает целые числа, да еще с разным знаком от нуля и тд. По итогам тестирования он оставляет самый удачный блок и переходит к другой задаче. 

 При этом, для начала не обязательно готовить столько много блоков, достаточно будет 2-х 3-х. Главное, наладить взаимодействие .

То же самое с зависимостями. Есть А, В, С. Проверяем сначала вариант если А больше В, то истинно С. потом если В больше А, и тд.

Затем уже можно перейти к более сложным взаимодействиям. 

 

"Чтобы снизить количество  вариантов и модификация в одном не затрагивала другой блоки должны быть ЕЩЕ более  универсальные." => "Скажем, мы выбрали стандарт взаимодействия - проценты от верха." - я понял вашу мысль)). Она предполагает приведение индикаторов к единому виду, т.е. предобработка. В моей системе слишком всё формализовано, хотелось бы это всё сохранить, я уже занимаюсь внедрением таких вещей как шкала, категория, уже придумал как это сделать, там действительно присоединение одних блоков влияет на подключения блоков в других местах. Стандартизация индикаторов идёт через описание самого индикатора и , в зависимости от её, будут автоматически присоединяться те или иные блоки. Одним из блоков запросто может быть расчёт процента одного значения от другого, только значения эти должны между собой иметь связь, что и будет контролироваться, например:

  1. Percent( Open[0] , Open[3] )
  2. Percent(Open[0], Alligator[3])
  3. Percent(Volume[0], Alligator[3])

1-й и 3-й варианты хорошие, логичные, а 3 не имеет смысла.

Индексы тоже будут рассчитываться,  например Open[ Max_on_position(iAC,0,30) ]

 
Youri Tarshecki:

 При этом, для начала не обязательно готовить столько много блоков, достаточно будет 2-х 3-х. Главное, наладить взаимодействие .

То же самое с зависимостями. Есть А, В, С. Проверяем сначала вариант если А больше В, то истинно С. потом если В больше А, и тд.

Затем уже можно перейти к более сложным взаимодействиям. 

 Это уже есть.

Реализовано следующим образом:

  1. есть базовые типы int,double,bool
  2. с базовых типов составляются сложные типы(можно их добавлять), например (int,double) - координата на графике, (x,b) - коэффициенты уравнения прямой, (a,b,c,d) - поддержка до 4-х значений
  3. индикаторы представляются как набор сложных типов с одним элементом
  4. константы представлены как сложные типы, это те параметры стратегии которые оптимизируются
  5. функции получают на вход определённые сложные типы переменных, количество их не ограничено, на выходе тоже получаются сложные типы
  6. функциям абсолютно не важно откуда эти данные взялись, главное чтобы было соответствие типов
  7. поддерживаются все ордера которые есть в mql4 (6 штук)
  8. стратегию определяет только один тип ордера(buy или sell или buy_stop или...)
  9. для не отложенных ордеров на вершине графа 4 узла: условие входа в рынок, условие выхода, tp и sl.
  10. блоки(функции/узлы графа) могут брать входные параметры с индикаторов, констант, других узлов, допускается, что с результата одного узла могут брать данные в качестве входных параметров множество других узлов, ограничений нету, не считая того, что нельзя допускать циклы в графе.
  11. потом граф транслируется в последовательный код, и этот код будет отправятся советнику на исполнение, ничего компилировать на MQL не надо
Вот пример кода:

#define
symbol          GBPUSD;
period          60;
repeat_signal_skip      True;
stop_level              60;
trade           op_buy;
max_shift               13;
stack           4;
const           9;
cache           1;
#data
{True},{-1.26761795},{4.67108999},
{2.08088665},{-0.33782435},{22},
{1.63150050},{-11},{-0.22006371};
#program
push    [0];
push    [1];
push    [2];
call    F_plus_d;
push    [3];
push    [4];
call    F_plus_d;
push    [5];
get     .Ichimoku_2;
call    F_plus_d;
push    [6];
call    F_minus_d;
save    [0];
push    [7];
get     .Open;
call    F_plus_d;
call    F_less;
load    [0];
push    [8];
#end

 Ещё не всё сделано, не вся необходимая информация есть в коде, код выполняется корректно с точки зрения контроля типов, бессмысленные выражения пока не учитываются

В коде используются только простые типы.

 

Предполагаю стратегии передавать по HTTP протоколу, в MQL есть возможность получать стратегии таким образом.

Хочу сделать полностью всё автоматизированно, поиск стратеги, составление портфелей стратегий, передача советнику и т.д.

 Чаcть системы на MQL готова на 90%, работа с множеством стратегий(контроль позиций, рисков, обработка ошибок и т.д).

Работы ещё много. 

 
Yuriy Asaulenko:
Если искать стратегию, то не проще. Про остальное не знаю, не думал на эту тему. Хотя, любое моделирование проще в спец средах, а не в МТ. МТ - это конечный продукт, для исследований не создан и не оч. подходит
Согласен, сам изначально идею в матлабе моделирую. Все же тестер МТ - черный ящик.
 
Aliaksandr Hryshyn:
Вот ещё пример бессмысленного выражения: =High>(Open-Close), тоже не проскочит.

А почему оно бессмысленное, объясните плз. Правда, я бы так записал

=High>MathAbs(Open-Close)

 

ю 

 

Aliaksandr Hryshyn:

потом граф транслируется в последовательный код, и этот код будет отправятся советнику на исполнение, ничего компилировать на MQL не надо


Каким образом, поясните плз?
 

Оно всегда будет возвращать true)).

(Open-Close) всегда будет меньше (High)

 
Alexey Volchanskiy:

Каким образом, поясните плз?
Что именно, транслироваться или исполняться?
 
Aliaksandr Hryshyn:

Оно всегда будет возвращать true)).

(Open-Close) всегда будет меньше (High)

Торможу ))))))))))
123456
Новый комментарий
Причина обращения: