"Генетические алгоритмы - это просто!" - продолжение следует? - страница 4

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

Для принятия решения все критерии так или иначе сводятся к одному показателю. Поэтому игры в "многокритериальные параметры наружу" не имеют смысла. Внутри OnTester можно иметь сколько угодно критериев, но в финале они превращаются в одиночный double.

Вопрос: какое решение для возможности отнормировать внутренние критерии для выдачи одно ответа в OnTester?

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

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

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

Документация по MQL5: Математические функции / MathAbs
Документация по MQL5: Математические функции / MathAbs
  • www.mql5.com
Математические функции / MathAbs - Документация по MQL5
 
Renat:

Расскажите в чём видите проблемы?

Так понимаю вас беспокоит увеличение трафика из-за передачи из каждой особи массива данных вместо одиночного double.

 

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

Можете вообще показать ошибку нормирования в кастомном критерии? Это ведь полностью в руках разработчика эксперта и можно использовать как относительные показатели, так и встроенные пределы для критериев.

 
Urain:

Расскажите в чём видите проблемы?

Так понимаю вас беспокоит увеличение трафика из-за передачи из каждой особи массива данных вместо одиночного double.

Проблему я вижу пока в том, что из пальца высасывают несуществующие проблемы.
 
Renat:

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

Можете вообще показать ошибку нормирования в кастомном критерии? Это ведь полностью в руках разработчика эксперта и можно использовать как относительные показатели, так и встроенные пределы для критериев.

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

Renat:
Проблему я вижу пока в том, что из пальца высасывают несуществующие проблемы.

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

 
Urain:

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

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

Я вник, решение запросил, но вместо решения получил предложение все кратно усложнить.

Свои решения для OnTester я предложил:

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

Эти решения уже сейчас доступны любому разработчику.

Документация по MQL5: Математические функции / MathAbs
Документация по MQL5: Математические функции / MathAbs
  • www.mql5.com
Математические функции / MathAbs - Документация по MQL5
 
Urain:

Потому что кастом не нормирует каждый критерий относительно своего диапазона.

Да, видно я совсем дуб дубом в генетике. Я искренне не понимаю смысла использования абсолютных критериев, когда можно создать свои отнормированные критерии в необходимых шкалах. Объясните мне, на кой черт использовать абсолютный NetProfit, вместо того же нормированного ERF, если они коррелируют друг с другом на 97,8%! 

 
Renat:

Для принятия решения все критерии так или иначе сводятся к одному показателю. Поэтому игры в "многокритериальные параметры наружу" не имеют смысла. Внутри OnTester можно иметь сколько угодно критериев, но в финале они превращаются в одиночный double.

Вопрос: какое решение для возможности отнормировать внутренние критерии для выдачи одно ответа в OnTester?

Renat:

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

Можете вообще показать ошибку нормирования в кастомном критерии? Это ведь полностью в руках разработчика эксперта и можно использовать как относительные показатели, так и встроенные пределы для критериев.

Renat:
Проблему я вижу пока в том, что из пальца высасывают несуществующие проблемы.

Не не. Проблема действительно есть. И решение есть, на стороне тестера (если разработчики озаботятся) и с помощью собственно языка MQL5 (планировалась платная библиотека, но если решение будет штатное, то в ней необходимость отпадет). 

Urain:

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

Не совсем так. Да, можно нормировать относительно результатов одной популяции по завершению эпохи. Но, практика показала, всё же эффективней помнить исторические минимумы и максимумы и нормировать относительно них.


Ну, собственно, и само решение.

Не буду рассказывать как это провернуть средствами MQL5, но предложу способ штатного решения на стороне тестера.

Есть такая функция double OnTester(), которая возвращает результат кастомного критерия оптимизации. Для адекватного проведения многокритериально  поиска, можно добавить такие передаваемые переменные:

double &Criteria[] и double &CriterionWeight[]. Тогда получится что то вроде такого:

#define CriteriaCount 10; //количество пользовательских критериев оптимизации

void OnTester(
              double &Criteria[],       // массив пользовательских критериев оптимизации
              double &CriterionWeight[] // веса пользовательских критериев оптимизации
             )
{
   ArrayResize(Criteria, CriteriaCount); ZeroMemory(Criteria);
   
   //тут как душе угодно задаём веса каждого из критериев
   for(int i=0;i<CriteriaCount;i++)
   {
     CriterionWeight[i]=1.0;
   }
   
   ///////////////////////////////////////////////////////
   // тут считаем критерии или используем стандартные функции статистики торговли
   Criteria[0]=Прибыль;
   Criteria[1]=просадка;
   ....
   Criteria[CriteriaCount-1]=КоличествоТрейдов;
   ///////////////////////////////////////////////////////
}

Вот собственно и всё.

Функция не должна иметь возвращаемого значения. В конце каждой эпохи тестер рассчитывает итоговое значение кастомного критерия оптимизации с учетом под-критериев в Criteria с весами в CriteriaCount.


А что бы сделать то же самое только средствами MQL5 - придется изрядно изловчится. Кроме того, мощь облака будет недоступна в этом случае.

 
В текущей реализации многокритериального поиска селекция ведётся однобоко - шибко волосаты "кролики" и чуть-чуть мясные. В результате получаем в конце оптимизации стадо волосатых "кроликов" и всего несколько штук мясных и с чудесным шелковистым мехом. Это не вина штатной генетики (пролетали тут со свистом камни в его огород). Это "заслуга" кастомного критерия в текущей реализации. Генетика ищет лишь то, что ей велели искать, но никак не " мясных и с чудесным шелковистым мехом". В правильной реализации с самого начала и до самого конца оптимизации эволюция будет идти в нужную сторону.
 
joo:
В текущей реализации многокритериального поиска селекция ведётся однобоко - шибко волосаты "кролики" и чуть-чуть мясные. В результате получаем в конце оптимизации стадо волосатых "кроликов" и всего несколько штук мясных и с чудесным шелковистым мехом. Это не вина штатной генетики (пролетали тут со свистом камни в его огород). Это "заслуга" кастомного критерия в текущей реализации. Генетика ищет лишь то, что ей велели искать, но никак не " мясных и с чудесным шелковистым мехом". В правильной реализации с самого начала и до самого конца оптимизации эволюция будет идти в нужную сторону.

А что мешает мешает использовать "встроенные в MQL5 код пределы критериев для автоматического нормирования" вместо вытаскивания их на уровень движка?

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

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

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