Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
это один и тот же результат! входные параметры для этих точек одинаковые!
Поясните, пожалуйста. Не понял про "входные параметры для этих точек одинаковые". Насколько я понимаю работу оптимизатора, каждому проходу соответствует уникальный набор входных параметров. Или Вы хотите сказать, что при использовании генетического алгоритма могут случаться ситуации, когда уникальный набор входных параметров может обрабатываться оптимизатором несколько раз?
...Ну да, именно это и сказано. Тогда получается, что все последующие точки "из кэша" - просто фикция, искажающая зрительное восприятие результатов оптимизации?
Странно. Уже который раз. На графике две близких по значению точки, а в результатах одна.
Подсказка: произведите, пожалуйста, сортировку по запрашиваемому показателю, и не забудьте показать вертикальную полосу прокрутки таблицы.
Вот эта проблема когда-нибудь решится???
Третий раз про неё говорю а реакции ноль!
кстати, мне кажется, что если выбрано моделирование реквотов, то этот кэш не должен использоваться. что на этот счёт думают разработчики?
и ещё, бага: когда у меня генетический алгоритм пошёл дальше 10496, график стал отображаться неверно - по вертикали он масштабировался правильно, можно было понять, что найдены более высокие результаты, а по горизонтали он не обновлялся. точки как буд-то добавлялись где-то справа, уже за границей графика.
В терминале результат
Результат в тестере:
Вся прелесть фунции SymbolName(i) пропадает
Просьба к разработчикам. Пока кипит работа над МТ5 и еще вносятся изменения, было бы очень здорово расширить количество проходов оптимизации.
Как я понял для очень многих задач решение находится примерно за 10 000 вариантов может немного больше, или немного меньше. Несколько часов перебора на одном процессоре и лучшие варианты найдены.
Универсальность MQL5+ООП+Многоядерное тестирование позволяют окинуть взглядом новые горизонты задач (например поиск патернов) которые могут быть решены средствами MT5.
Но вот незадача:
В статье, опубликованной на вашем сайте есть пример генетического алгоритма https://www.mql5.com/ru/articles/55, где для решения задачи поиска на 100 барах понадобилось 3^100 прямого перебора - ну это немного больше, чем LongInt :) а решение было найдено за 17 000 итераций. Генетический алгоритм может находить решения среди намного большего количества вариантов, чем LongInt. А это ограничение совершенно ни чем не обоснованно и устарело. Ну разве, что на данном заключительном этапе работы над МТ5 это будет сложно сделать.
Огромная просьба к разработчикам, если это не очень сложно, сделайте пожалуйста количество проходов ну хотя бы 2^LongInt (2 в степени).
Код:
Лог:
2010.12.06 18:07:52 testInd (EURUSD,H1) Измененный? Handle2 =10
2010.12.06 18:07:52 testInd (EURUSD,H1) Handle2 =10
2010.12.06 18:07:52 testInd (EURUSD,H1) Handle1 =10
Соответственно все обращения за данными к handle2 равноценны обращению к handle1, хотя период измененный.
В ходе работы советника не исключается создание индикаторов с одинаковыми характеристиками, и такая оптимизация к одному хэндлу разумна, но такое "залипание" хэндла к переменной очень портит жизнь.
P.S. Выяснил причину. Это баг - следствие оптимизации к одному номеру хендла.
IndicatorRelease(handle2); //уменьшает счетчик хендлов на единицу и в итоге следующий созданный хэндл(с любой переменной) - опять 10
Код:
Лог:
2010.12.06 18:07:52 testInd (EURUSD,H1) Измененный? Handle2 =10
2010.12.06 18:07:52 testInd (EURUSD,H1) Handle2 =10
2010.12.06 18:07:52 testInd (EURUSD,H1) Handle1 =10
Соответственно все обращения за данными к handle2 равноценны обращению к handle1, хотя период измененный.
В ходе работы советника не исключается создание индикаторов с одинаковыми характеристиками, и такая оптимизация к одному хэндлу разумна, но такое "залипание" хэндла к переменной очень портит жизнь.
P.S. Выяснил причину. Это баг - следствие оптимизации к одному номеру хендла.
А почему вы решили что это именно баг?
А почему вы решили что это именно баг?
Если, к примеру, пользователь вводит значения периода для MA из интерфейса, создавая хендлы для индикаторов и используя значения буферов индикаторов, то, создав, пускай случайно (у меня к примеру стоят в этой форме дефолтные настройки) 2 индикатора с одинаковыми характеристиками (их хендлы кладутся в объектную обертку), он получает, вследствии этой фичи для второго индикатора номер хэндла первого.
Следующие возможные цепочки событий.
Ситуация 1. Он удаляет первый индикатор(и программа делает IndicatorRelease) следствие - второй автоматически не работает - ошибка копирования буферов.
Ситуация 2. Он удаляет второй индикатор(и программа делает IndicatorRelease), хендл счетчик уменьшается. Первый при этом прекрасно себя чувствует. Создает третий индикатор с другим периодом. Ему отдается хендл счетчик+1 т.е. номер хендла только что удаленного индикатора. В итоге, самое ужасное, третий индикатор, с другим периодом, успешно созданный, отдает в буфер значения первого, по прежнему, неудаленного индикатора.
Фича склейки номеров хендлов, приводит к неоднозначным ситуациям при удалении одного из двух склеенных и последующем создании новых хендлов.
А мне кто-нибудь ответит?
Здесь говорили об этом. https://www.mql5.com/ru/forum/1997/page6/#comment_31644
Может лучше туда вопрос - предложение перенести.