Не для разработчиков МТ! Чем заменить INIT_PARAMETERS_INCORRECT ?

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

Столкнулся с такой проблемой: по логике программы существует необходимость отсеять не допустимые варианты вызова функций. Использую для этого INIT_PARAMETERS_INCORRECT. Но генетическая оптимизация стопориться практически сразу. Разработчиков аж бесят вопросы касающиеся этой ситуации. Советуют учить генетический анализ и т.п. и т.д..

А на кой мне это надо? Я, как пользователь, хочу получить результат, а как оно там работает - мне глубоко фиолетово.

Так вот, пример на трёх функциях 1, 2 и 3. 0 - это не использовать.

В цепочке функции не должны повторяться и между функциями не должно быть 0-я (иначе возможны повторения). 

Пример допустимых цепочек:

  • 100
  • 120
  • 130
  • 123
  • 132
  • 2..
  • 3..

Пример не допустимых цепочек:

  • 010
  • 001
  • 110
  • 101
  • 111
  • 121
  • 122
  • 131
  • 133
  • 112
  • 113
  • 102
  • 103
  • 2..
  • 3..
Как видно, недопустимых цепочек на порядок больше чем допустимых. Как произвести выборку? Чем заменить INIT_PARAMETERS_INCORRECT ? Куда копать?

 
Отменить вычисления в On-функциях, если параметры левые. Прогоны будут медленнее 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 ! Медленным перебором не обойти.
 
Сергей Таболин:
Это не наборы входных параметров! Это набор функций, которые не должны повторяться! В медленной оптимизации INIT_PARAMETERS_INCORRECT реально помогает выстроить допустимые цепочки вызова этих функций, но их у меня 6. Вариантов цепочек 117649. Но эти цепочки бесполезны без некоторых входных параметров. А с ними уже получается более 38 000 000 ! Медленным перебором не обойти.

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


Можете поставить такой эксперимент. Взять стандартный советник и добавить туда несколько доп. входных параметров для оптимизации - фейковых. Сделав 90% их наборов INCORRECT. ГА загнется. Хотя без фейк-параметров неплохо справится с задачей.

 
fxsaber:

Понял. Только вопрос то как раз в том, чтобы в оптимизаторе подобрать подходящие функции и их порядок. А вручную прописывать все не подходящие цепочки.... И как же тогда оптимизатор найдёт их?

 
fxsaber:

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

Я это понимаю. Не понимаю только как это обойти?

 
Сергей Таболин:

Я это понимаю. Не понимаю только как это обойти?

Один из рецептов, чтобы разработчики результат INCORRECT-проходов считали, как ближайший посчитанный ранее CORRECT-проход. Это нивелирует дыры в оптимизационной поверхности.

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