Не для разработчиков МТ! Чем заменить INIT_PARAMETERS_INCORRECT ?
Более внятно можно изложить возможные наборы входных параметров, нежелательные наборы, и почему нежелательных наборов получается слишком много ?
Я полностью согласен с разработчиками, что нежелательных наборов не должно быть слишком много. Оптимально - не более 10%
Это как? Можно малюсенький пример?
fxsaber прав.
Если на вход подаются неверный набор параметров - все OnTick() функции сразу возвращаешь. И на OnTester - возвращаешь самый минимальный результат.
Это как? Можно малюсенький пример?
input int i = 0; bool Incorrect; int OnInit() { Incorrect = !i; // нулевое значение считается некорректным (пример) // return(Incorrect ? INIT_PARAMETERS_INCORRECT : INIT_SUCCEEDED); // Было return(INIT_SUCCEEDED); } void OnTick() { if (Incorrect) return; // ... }
Это не наборы входных параметров! Это набор функций, которые не должны повторяться! В медленной оптимизации INIT_PARAMETERS_INCORRECT реально помогает выстроить допустимые цепочки вызова этих функций, но их у меня 6. Вариантов цепочек 117649. Но эти цепочки бесполезны без некоторых входных параметров. А с ними уже получается более 38 000 000 ! Медленным перебором не обойти.
Генетика сдохнет, т.к. оптимизационная поверхность критерия оптимизации должна быть более-менее непрерывной (гладкой). В Вашем же случае получается огромное количество всплесков (провалов).
Можете поставить такой эксперимент. Взять стандартный советник и добавить туда несколько доп. входных параметров для оптимизации - фейковых. Сделав 90% их наборов INCORRECT. ГА загнется. Хотя без фейк-параметров неплохо справится с задачей.
Понял. Только вопрос то как раз в том, чтобы в оптимизаторе подобрать подходящие функции и их порядок. А вручную прописывать все не подходящие цепочки.... И как же тогда оптимизатор найдёт их?
Генетика сдохнет, т.к. оптимизационная поверхность критерия оптимизации должна быть более-менее непрерывной (гладкой). В Вашем же случае получается огромное количество всплесков (провалов).
Я это понимаю. Не понимаю только как это обойти?
Я это понимаю. Не понимаю только как это обойти?
Один из рецептов, чтобы разработчики результат INCORRECT-проходов считали, как ближайший посчитанный ранее CORRECT-проход. Это нивелирует дыры в оптимизационной поверхности.
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Вы принимаете политику сайта и условия использования
Столкнулся с такой проблемой: по логике программы существует необходимость отсеять не допустимые варианты вызова функций. Использую для этого INIT_PARAMETERS_INCORRECT. Но генетическая оптимизация стопориться практически сразу. Разработчиков аж бесят вопросы касающиеся этой ситуации. Советуют учить генетический анализ и т.п. и т.д..
А на кой мне это надо? Я, как пользователь, хочу получить результат, а как оно там работает - мне глубоко фиолетово.
Так вот, пример на трёх функциях 1, 2 и 3. 0 - это не использовать.
В цепочке функции не должны повторяться и между функциями не должно быть 0-я (иначе возможны повторения).
Пример допустимых цепочек:
Пример не допустимых цепочек: