Диапазон оптимизации - страница 4

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

Задача оптимизации - выявить такие параметры ТС, при которых мы получаем стабильный результат на тестируемом промежутке... Чем шире временной диапазон, тем больше можно доверять полученным результатам в будущем.... При тестировании мы получаем, практически, полную информацию... Хотелось бы еще увидеть кривые баланса и эквити в зависимости от временного промежутка... Но видимо это все мечты...

Вопрос: зачем нужны эти кривые? Чтобы по ним нарисовать уже ломанные линии, а точнее зигзаг для определения экстремумов.... Взлеты и падения... Полученные результаты анализируем и подбираем параметры...

Сегодня после тестирования нам известен только один экстремум: максмимальная просадка, что явно малова-то ...

 
Vinsent_Vega писал(а) >>

что верно, то верно... вот я и думаю: верить Neutron'у на слово или нет...

оптимизационно - это как? просто прооптимизировал своего советнега что-ли? я думал тут какие-то серьезные исследования проводились... (сам-то Ежова не читал, поэтому думал это его цифирь - "4")


Vinsent, я ж не апостол, чтобы в меня верили. Всё, что я привёл в постах, легко проверяется путём банального повторения.

Что касается коэффициента, то его можно определить двумя не пересекающимися способами - прямым выводом, что для меня сложно, и оценочно. Ежов и Шумский показали аналитическую зависимость оптимальной длины истории от числа настраиваемых параметров с точностью до константы порядка единицы. Полученная зависимость не несёт каких либо ограничений на область применения, поэтому достаточно на нескольких примерах найти оптимальное её значение и убедится в его стационарности, что бы не морочить себе голову сложными математическими выкладками без особой нужды. Что и было проделано.

 

ладно, и на этом спасибо... :)


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


но видимо, придется опираться только на свой опыт и интуицию...

 
Vinsent_Vega писал(а) >>

я почему так придираюсь - для меня этот вопрос (диапазон оптимизации) сейчас центральный... может rider и прав...

На самом деле прав не rider, а, скорее, kharko :

kharko писал(а) >>

Задача оптимизации - выявить такие параметры ТС, при которых мы получаем стабильный результат на тестируемом промежутке... Чем шире временной диапазон, тем больше можно доверять полученным результатам в будущем....

Проблема гораздо шире и деликатнее, как это не парадоксально. Действительно, если обратиться к формуле, которая показывает зависимость ошибки обобщения тестера стратегий то видно, что она монотонно спадает с ростом числа трансакций Р: E=Eapprox+ Ecomplex=d/W+W/P, т.е. чем больше обучающая выборка тем лучше... но, это верно в предположении неизменности (стационарности) рынка, а он на самом деле изменчив и начиная с какого-то Р примеры становятся бесполезными, более того - вредными. В этих условиях актуально определить границу, после которой дальнейшее наращивание числа примеров только ухудшает ситуацию. Нужно определить левый предел по параметру Р. Это наступит тогда, когда ошибка связанная со сложностью модели сравнима с ошибкой аппроксимации или чуть меньше последней, а не стремиться к нулю, как было бы в случае предлагаемом kharko . Поэтому, есть пологий оптимум по параметру Р=k*W в районе k=3-6.

Вот, откуда берётся этот коэффициент, он имеет своей природой нестационарность процессов на рынке.

 
Neutron >>:

На самом деле прав не rider, а, скорее, kharko :

Проблема гораздо шире и деликатнее, как это не парадоксально. Действительно, если обратиться к формуле, которая показывает зависимость ошибки обобщения тестера стратегий то видно, что она монотонно спадает с ростом числа трансакций Р: E=Eapprox+ Ecomplex=d/W+W/P, т.е. чем больше обучающая выборка тем лучше... но, это верно в предположении неизменности (стационарности) рынка, а он на самом деле изменчив и начиная с какого-то Р примеры становятся бесполезными, более того - вредными. В этих условиях актуально определить границу, после которой дальнейшее наращивание числа примеров только ухудшает ситуацию. Нужно определить левый предел по параметру Р. Это наступит тогда, когда ошибка связанная со сложностью модели сравнима с ошибкой аппроксимации или чуть меньше последней, а не стремиться к нулю, как было бы в случае предлагаемом kharko . Поэтому, есть пологий оптимум по параметру Р=k*W в районе k=3-6.

Вот, откуда берётся этот коэффициент, он имеет своей природой нестационарность процессов на рынке.

Бог с ней с правотой.... не настаиваю, да и права такого за собой не нахожу )))..... очень бы хотелось поверить в ваш k=3-6 и обойтись при этом без всяких форвардов...... (((..... но что-то не пускает, а самое главное, что рутинных операций меньше не становиться: можно бы было задать в оптимизаторе количество сделок на определенный интервал - совсем другой разговор пошел бы..... 

а можно ссылочки на Ежова и т.д. плз???

 
rider писал(а) >>

а можно ссылочки на Ежова и т.д. плз???

Лови, стр.64-66.

Файлы:
ts.zip  1592 kb
 
благодарю
 
Neutron писал(а) >>

Не-не. Погоди!

Частота сделок сама-по-себе, а оптимальное их число на тестовой истории - само-по-себе. Ты оптимизируешь параметры ТС глядя на результаты торгов -находишь максимум некоего функционала, в данном случае, это может быть комулятивный доход или профитность (число пунктов на трансакцию). Теперь так, у тебя стоит вопрос: при заданном количестве настраиваемых параметров, нужно найти самое оптимальное количество трансакций на которых тестер будет оптимизировать стратегию. Заметь, не время, а именно число входов-выходов на рынок.

Короче, в задачу входит только число сделок - их не должно быть больше или меньше оптимального. Нашёл оптимум по доходности - торгуешь. Через какой-то промежуток времени запускаешь переоптимизацию и так всё время. Как это реализовать в тестере? Нужно думать...

....

Если у нас в тестере оптимизируются 5 параметров (нарпимер, периоды машек), то оптимальная длина истории должна быть такой, что бы тестером было совершено на ней 4*5=20 трансакций. Для этого может потребоваться от 1 до ...200 дней истории, всё зависит от принятой стратегии. Уменьшение этого числа, приведёт к подгонке тестера под историю, а увеличение - к ухудшению качества аппроксимации и, как следствие, к ухудшению точности прогноза.

Привел выдержки из ваших постов.... Делаем выводы...

Вы утверждаете, что существует некое оптимальное количество сделок, зависящее от количества подгоночных параметров... Ок... согласимся....

Теперь наша задача состоит в том, чтобы для каждого прогона найти оптимальный временной диапазон, в котором ТС осуществила расчетное оптимальное количество сделок.... Т.е. для одних параметров достаточно истории в 1 день, а для других и года не хватит... Такой вариант не подходит...

Хорошо... Упростим задачу.... Оставим постоянный временной интервал... В рассмотрении оставим только те прогоны, которые дают нам оптимальное количество сделок...

Какой из них лучший? Ответ очевиден... Тот, у которого наибольшее матожидание....

А как же быть с теми прогонами, которые мы отсеяли?... Разве они не пригодны?

Допустим, оптимальное количество сделок равно N... Есть такой прогон с таким количеством сделок... Но есть прогон, в котором сделок больше в К раз...

Пока наш идеальный прогон совершит 1 сделку, другой не идеальный по количеству сделок, уже совершит К сделок....

Теперь сравним прибыль, которую получим от идеального и не идеального прогонов... Для этого умножаем количество сделок на соответствующее значение матожидания...

Если прибыль от неидеального прогона окажется больше, то это означает, что мы взяли слишком большой временной период для оптимизации для этого прогона, т.к получили количество сделок отличное от оптимального... Снова нестыковка...

Даже если взять 1 прогон, который удовлетворяет условию оптимального количества сделок, то стоит нам только сдвинуть временной интервал вправо или влево, мы получим другие результаты по количеству сделок...

Вывод: предложенный метод оптимизации утопия.

 

to Neutron

По поводу количества сделок еще одно замечание: У меня в советнике есть такой параметр как максимальное количество ордеров и при правильно подобранных параметрах увеличение одновременного количества сделок которые делает советник увеличивает полученную прибыль, но с другой стороны, мы получаем неоптимальное количество сделок на данном временном диапазоне по соотношению к количеству входных параметров советника, как с этим быть?

 

Не хотите ли рассмотреть вот такой вариант оптимизации и бэктеста:

int start()
{
   if(IsTesting()==true)
   {
      if(IsOptimization()==true && DayOfWeek()&0xE==DayOfWeek())return;
      if(IsOptimization()==false && DayOfWeek()&0xE!=DayOfWeek())return;
   }
//код советника
//код советника
}

Вместо 

DayOfWeek()
можно поставить другую функцию, например,

Month()

или наоборот - более мелкую 

  Hour()
1234567
Новый комментарий