MetaTrader 5 Strategy Tester! - страница 88
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Меня не особо напрягает, что MQ-алгоритм уступает Вашему и довольно существенно. Бесит, что многоядерные мат. оптимизации в MQ производятся на порядки медленней по времени.
Неприятно, что Облако за деньги медленней на мат. задачах, чем free-лаконичные в реализации алгоритмы. Т.е. использовать Облако для мат. расчетов имеет смысл только в том случае, если одиночный расчет ФФ занимает огромное время. А это сверх-низкая часть от всех мат. расчетов. Пакетирование, как в случае с полным перебором, здесь не прокатит.
Фактически, Облако для мат. расчетов целесообразно только при полном переборе.
В корне ошибочное заявление.
Когда у вас целевая функция занимает микросекунды, то жаловаться на системный оверхед инфраструктуры странно:
Все это является универсальным движком с легким анализом результатов.
И все это против нативного: причем именно нативного 64 битного кода
{
Init();
Calc();
Deinit();
}
Уйдите из расчетов сферического коня в реальные задачи со временем целевой функции хотя бы в секунды и сразу все станет на свои места.
Теперь мой анализ исходной задачи по поиску 50 символьной строки.
Зная алгоритм нашего генетического оптимизатора, я сразу сказал, что исходная фитнес функция явно ошибочна и постоянно вводит в заблуждение оптимизатор, выдавая одинаковые значения [0,50] при разных результатах. Фактически оптимизатор вводится в ступор, так как он не видит гладкой/постоянно увеличивающейся функции и не знает в какую сторону вести улучшения.
{
double rating=0;
//---
for(int i=0;i<ArraySize(ExtTarget);i++)
if(ExtTarget[i]==ExtOriginal[i])
rating++;
//--- вернем результат
return(rating);
}
{
double rating=0;
//---
for(int i=0;i<ArraySize(ExtTarget);i++)
if(ExtTarget[i]==ExtOriginal[i])
rating+=1+MathSqrt(i+1);
//--- вернем результат
return(rating);
}
Новая функция лучше из-за того, что у нее нет равности результата совпадения 1 или 10 символа.
Вот как выглядят функции графически - синяя старая и красная новая:
Через несколько запусков у меня получился результат в 46 найденных символов из 50, что дает 92%:
Result: 'giplioxsxofxresidentsxchinasxnorthwesternxrenionsx' percent: 92.0%%
Мои выводы:
Точь в точь тема поднималась больше 10 лет назад и ситуация была точно такой же: частное решение vs универсальное. Прочтите всю ветку, если интересно.
У нас уже запланирован апгрейд тестера ради удобства использования. Заодно проверим глубже генетический оптимизатор и почему он не дотягивает до более лучших результатов при указанных фитнес-функциях.
Уйдите из расчетов сферического коня в реальные задачи со временем целевой функции хотя бы в секунды и сразу все станет на свои места.
Это читали?
использовать Облако для мат. расчетов имеет смысл только в том случае, если одиночный расчет ФФ занимает огромное время. А это сверх-низкая часть от всех мат. расчетов.
Про "секунды" на ФФ нигде не сказано в описании мат. расчетов. Попробуйте придумать такую ФФ. Лично я не в курсе, какие реальные мат. задачи требуют оптимизации ФФ, одиночный расчет которой занимает многие секунды.
Хорошо, что прояснили практическую часть мат. режима оптимизатора. Как итог, оптимизатор и тем более Облако имеет смысл использовать для ОЧЕНЬ медленных (многие секунды) ФФ. Если ФФ считается быстро - Облако и оптимизатор MQ ни в коем случае использовать не нужно: потеря времени и денег (в случае Облака).
Это читали?
Про "секунды" на ФФ нигде не сказано в описании мат. расчетов. Попробуйте придумать такую ФФ. Лично я не в курсе, какие реальные мат. задачи требуют оптимизации ФФ, одиночный расчет которой занимает многие секунды.
Хорошо, что прояснили практическую часть мат. режима оптимизатора. Оптимизатор и тем более Облако имеет смысл использовать для ОЧЕНЬ медленных (многие секунды) ФФ. Если ФФ считается быстро - Облако и оптимизатор MQ ни в коем случае использовать не нужно: потеря времени и денег (в случае Облака).
Все читал.
Секунда на расчет - это очень медленно? Да вы видимо не знаете, что и зачем считать. Уйдите от фейкового микросекундного тела в цикле for и все станет ясно.
И даже системный оверхед в указанной задаче позволяет получить результат за 50-70 секунд с полным фаршем подготовленных результатов, логов и графики для любых универсальных задач. Это что - сверх много? Или все-таки отсутствие здравого смысла у критика?1. Зная алгоритм нашего генетического оптимизатора, я сразу сказал, что исходная фитнес функция явно ошибочна и постоянно вводит в заблуждение оптимизатор, выдавая одинаковые значения [0,50] при разных результатах. Фактически оптимизатор вводится в ступор, так как он не видит гладкой/постоянно увеличивающейся функции и не знает в какую сторону вести улучшения.
2. Новая функция лучше из-за того, что у нее нет равности результата совпадения 1 или 10 символа.
1. Нужно либо говорить "Наш алгоритм - универсальное решение" и не пенять на "ошибочность" или "неправильность" ФФ, либо признать, что алгоритм не универсален.
2. Фактически Вы подогнали ФФ под свой алгоритм, полностью нивелируя "изюм" ФФ - дискретность, которая в той или иной степени присутствует при оптимизации любого советника. Получается представляя публике оптимизатор для советников Вы сетуете, что тестовая задача как в советниках, это противоречие.
Мои выводы:
1. Неправильных ФФ не бывает. Есть такие, которые не решаются никакими алгоритмами, и есть такие которые одними решаются а другими нет. Оптимизация советников - архисложная задача, которую с разным успехом осуществляют трейдеры, и понять, почему тот или иной советник "не оптимизируется" пользователю очень сложно, если вообще возможно.
2. Этот подход вполне оправдан и я нигде особо не упирал на количество проходов как основной показатель и приводил сравнение результатов тестов с проходами которые равны или очень близки с Вашим алгоритмом. То есть делал сравнение результатов в одинаковых количествах проходов.
3. Когда я разрабатывал свой алгоритм я сразу делал упор на универсальность, не пытался выбирать "вот эти задачи подходят, а вот эти не подходят" потому что это было бы тупиковое развитие и путь в "заточенность" под узкий спектр задач. Наоборот, на протяжении многих лет выискивал и часто сам часами днями конструировал задачи с ФФ таким образом, что бы "убить" алгоритм, что бы запутать алгоритм в поиске, то есть делал всё, что бы максимально усложнить оптимизацию своему алгоритму. И когда я находил такие задачи, то исправлял алгоритм каждый раз расширяя спектр задач. Потому что если я находил какую то ФФ, с которой бы не справлялся мой алгоритм, то это ставило жирный крест на универсальности, сразу и бесповоротно. Нельзя быть чуть чуть беременным, или чуть чуть универсальным, в плане универсальности не может быть компромиссов.
Поэтому я и настаивал раньше, и настаиваю сейчас, представьте свои варианты сложных ФФ, что бы мы могли с интересом и пользой провести время, и если Вы представите задачу, которая будет на по зубам моему алгоритму, то я скажу только спосибо, потому что это будет вызов "универсальности" моему алгоритму. Мой алгоритм в текущей реализации настолько далёк от "Классических" представлениях о ГА, что по своим свойствам мало похож на генетические алгоритмы вообще. Ему не присущи обычные болячки ГА.
4. Это очень хорошо, что будут улучшения и пересмотр возможностей штатного алгоритма. Надеюсь изменения будут именно в сторону универсальности.
Всем доброго здоровья.
У меня возникла необходимость получать данные индикатора при открытии свечи, но с разными входными данными. Всё бы хорошо, только вот "При работе в тестере стратегий функция IndicatorRelease() не выполняется."!
Из-за этого в визуальном режиме на график постоянно добавляется индикатор, но не удаляется. Что в итоге получается, думаю догадались.
Но и это не беда. Беда в том, что оптимизация "зависает"!
Может кто знает КАК с этим бороться? Как освобождать память от хэндла индикатора в тестере?
Никак, это давняя проблема. Это один из способов написания вирусов на MQL (по крайней мере один способ я знаю - этот, свой комп вешал тыщу раз так), таким образом можно наглухо вешать операционную систему как только пользователь запустит подобный "вирус" в оптимизаторе.
Поэтому, например, невозможно использовать автооптимизацию советника в тестере с внешними индикаторами, не получится сделать валк-форвард тестирование.
Переносите код индикатора в советник, это единственный способ избежать подобных проблем.
1. Нужно либо говорить "Наш алгоритм - универсальное решение" и не пенять на "ошибочность" или "неправильность" ФФ, либо признать, что алгоритм не универсален.
2. Фактически Вы подогнали ФФ под свой алгоритм, полностью нивелируя "изюм" ФФ - дискретность, которая в той или иной степени присутствует при оптимизации любого советника. Получается представляя публике оптимизатор для советников Вы сетуете, что тестовая задача как в советниках, это противоречие.
Нет, не подогнал. Просто за пару часов чуть улучшил предложенную заведомо плохую фитнес-функцию.
Посмотрите на определение фитнес функции и увидите, что к ней обязательное требование - гладкость функции:
The fitness function is defined over the genetic representation and measures the quality of the represented solution. The fitness function is always problem dependent.
1. Неправильных ФФ не бывает. Есть такие, которые не решаются никакими алгоритмами, и есть такие которые одними решаются а другими нет. Оптимизация советников - архисложная задача, которую с разным успехом осуществляют трейдеры, и понять, почему тот или иной советник "не оптимизируется" пользователю очень сложно, если вообще возможно.
2. Этот подход вполне оправдан и я нигде особо не упирал на количество проходов как основной показатель и приводил сравнение результатов тестов с проходами которые равны или очень близки с Вашим алгоритмом. То есть делал сравнение результатов в одинаковых количествах проходов.
3. Когда я разрабатывал свой алгоритм я сразу делал упор на универсальность, не пытался выбирать "вот эти задачи подходят, а вот эти не подходят" потому что это было бы тупиковое развитие и путь в "заточенность" под узкий спектр задач. Наоборот, на протяжении многих лет выискивал и часто сам часами днями конструировал задачи с ФФ таким образом, что бы "убить" алгоритм, что бы запутать алгоритм в поиске, то есть делал всё, что бы максимально усложнить оптимизацию своему алгоритму. И когда я находил такие задачи, то исправлял алгоритм каждый раз расширяя спектр задач. Потому что если я находил какую то ФФ, с которой бы не справлялся мой алгоритм, то это ставило жирный крест на универсальности, сразу и бесповоротно. Нельзя быть чуть чуть беременным, или чуть чуть универсальным, в плане универсальности не может быть компромиссов.
Поэтому я и настаивал раньше, и настаиваю сейчас, представьте свои варианты сложных ФФ, что бы мы могли с интересом и пользой провести время, и если Вы представите задачу, которая будет на по зубам моему алгоритму, то я скажу только спосибо, потому что это будет вызов "универсальности" моему алгоритму. Мой алгоритм в текущей реализации настолько далёк от "Классических" представлениях о ГА, что по своим свойствам мало похож на генетические алгоритмы вообще. Ему не присущи обычные болячки ГА.
4. Это очень хорошо, что будут улучшения и пересмотр возможностей штатного алгоритма. Надеюсь изменения будут именно в сторону универсальности.
Еще как бывают.
Результат генетического подбора прямо зависит от качества фитнес функции и фитнес функция всегда зависит от задачи. Под каждую задачу надо вдумчиво писать функцию оценки, понимая механику генетического алгоритма.
Вы пропустили мимо вопрос "как получилось, что при заведомо слабой фитнес функции результат получился хороший"? Я не зря говорю про частные случаи и самообман. Особенно при полностью закрытой реализации.
1. Нет, не подогнал. Просто за пару часов чуть улучшил предложенную заведомо плохую фитнес-функцию.
Посмотрите на определение фитнес функции и увидите, что к ней обязательное требование - гладкость функции:
The fitness function is defined over the genetic representation and measures the quality of the represented solution. The fitness function is always problem dependent.
Еще как бывают.
2. Результат генетического подбора прямо зависит от качества фитнес функции и фитнес функция всегда зависит от задачи. Под каждую задачу надо вдумчиво писать функцию оценки, понимая механику генетического алгоритма.
3. Вы пропустили мимо вопрос "как получилось, что при заведомо слабой фитнес функции результат получился хороший"?
4. Я не зря говорю про частные случаи и самообман. Особенно при полностью закрытой реализации.
1. Требование гладкости - чистая подгонка. Если Ваш алгоритм требует гладкости ФФ - значит он плохо подходит под задачи трейдеров. И это крест на универсальности. Значит Ваш алгоритм не универсален, если требует подгонки ФФ под алгоритм.
2. Вы считаете, что пользователь обязан знать тонкости и особенности генетических алгоритмов, что бы результативно работать со штатным оптимизатором? Это второй жирный крест на универсальности.
3. Что значит "заведомо слабой фитнес функции" результат получился хороший? Почему тогда у Вас не очень хороший? Проблема со "слабыми ФФ"? Это третий жирный крест на универсальности.
4. Ваш алгоритм не менее закрытый чем мой и тесты проводятся на Вашей платформе. И я честно организовал тесты таким образом, что бы и Ваш и мой алгоритм обращались к одной и той же ФФ. Вы считаете, что я мог вшить в свой алгоритм все существующие задачи и типы задач в свой алгоритм? Даже если бы это было возможно, каким образом мой ао определяет, что за задача в данный момент в библиотеке ФФ, Вы же видили исходники ФФ, там узнать что внутри не возможно. Это конкретный беспочвенный наезд на мой ао при том, что Вы упорно отказываетесь представить на тест свою задачу.
Если знаете способ телепатически узнать содержимое *.ex5 (судя по Вашим словам это возможно и мой алгоритм умеет это делать), то я такого способа не знаю.
Посмотрите на определение фитнес функции и увидите, что к ней обязательное требование - гладкость функции.
Это OnTester советника гладкая ФФ?
Под каждую задачу надо вдумчиво писать функцию оценки, понимая механику генетического алгоритма.
Перефразируя: Под каждую ТС надо вдумчиво писать критерий оптимизации (OnTester), понимая механику генетического алгоритма.
Я не зря говорю про частные случаи и самообман. Особенно при полностью закрытой реализации.
Это конкретный беспочвенный наезд на мой ао при том, что Вы упорно отказываетесь представить на тест свою задачу.
Как только будет найдена ФФ способная превзойти существенно Ваш алгоритм мы её увидим.
У всех есть слабые места, но куда лучше было бы объединить сильные...