Ошибки, баги, вопросы - страница 739

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

Оптимизируйте по битным полям, в таком варианте лишних проходов не будет.

например:

input int bp=0;
int a=0;
int b=0;
Start()
{
 switch(bp)
   {
    case 0: a=0; b=0; break;
    case 1: a=0; b=1; break;
    case 2: a=1; b=0; break;
    default: a=1; b=1; break;    
   }
}

и оптимизируйте в заданных параметрах, для данного примера bp оптимизируется от 0 до 3

 
ivandurak:
 Только вы вердикт забыли написать можно или нет.     
Я ничего не забыл :) Если бы точно знал, как грамотно поступить, рассказал бы. Отрицательный же вердикт выносить - это несколько самонадеянно, так как незнание решения ещё не означает отсутствие этого самого решения. 
 
Идея понятна. Интересно генетика от такого фокуса с ума не сойдет. Получается в принципе рабочий набор параметров дает нулевой результат и в дальнейшей селекции не участвует. Имхо лучше в пожелания метаквотовцам написать, что то типа связанные оптимизируемые параметры, если это фальсе то это перебирать не надо.
 
Yedelkin:

Да как же "проще"? :) Наличие условий хоть для удаления эксперта, хоть для REASON_INITFAILED - всё равно нужно отслеживать. Вот это-то и выглядит муторно.

При отсутствии элегантного решения можно сначала использовать тот, что "проще". Найдётся что-то лучше, всегда можно заменить. :)
 
ivandurak:
 Получается в принципе рабочий набор параметров дает нулевой результат и в дальнейшей селекции не участвует.
 Не совсем так, если речь идёт про мою муторную идею. При "рабочем наборе параметров" и первом  trpar2=false проход выдаст вполне себе рабочий результат. При всех же последующих проходах с тем же "рабочим набором параметров" и trpar2=false будут сразу выдаваться нули, но при этом Ваш "рабочий набор параметров" в селекции-то поучаствует по-любому, а дублирующие проходы отсекутся. Ведь именно этого Вы хотели?
 
tol64:
При отсутствии элегантного решения можно сначала использовать тот, что "проще". Найдётся что-то лучше, всегда можно заменить. :)
 Ещё раз: муторность не в том, какой командой досрочно завершить проход - это достаточно примитивное решение, каким бы оно не было. Муторность - в отслеживании условий для досрочного завершения прохода. От того, что  проход будет завершаться досрочно с помощью Вашего предложения, муторность самого "блока слежения" никак не уменьшается, а элегантность этого блока никак не увеличивается.
 
Yedelkin:
 Не совсем так, если речь идёт про мою муторную идею. При "рабочем наборе параметров" и первом  trpar2=false проход выдаст вполне себе рабочий результат. При всех же остальных проходах с тем же "рабочим набором параметров" и trpar2=false будут сразу выдаваться нули, но при этом Ваш "рабочий набор параметров" в селекции-то поучаствует по любому. Ведь именно это Вы хотели?

Можно чуть поправить.  Оптимизационные параметры записывать в структуры, а с ними (структуры  простые) работать как с переменными. Что то такое

if(!trpar && Par1==Parold1 && Par2==Parold2) { Parold1=Par; Parold2=Par2 ; return(9) }    Здесь Par и Parold структуры в которые пишутся оптимальные параметры с других валютных пар. Сколько пар столько и ифов , выглядит не так уж безобразно. Спасибо.

 
Yedelkin:
 Ещё раз: муторность не в том, какой командой досрочно завершить проход - это достаточно примитивное решение, каким бы оно не было. Муторность - в отслеживании условий для досрочного завершения прохода. От того, что  проход будет завершаться досрочно с помощью Вашего предложения, муторность самого "блока слежения" никак не уменьшается, а элегантность этого блока никак не увеличивается.

Ну и что Вы хотели этим сказать? Что при отсутствии элегантного решения не использовать вообще никакой? Даже, если он есть, но, как Вы выражаетесь - "муторный"?

Короче, проехали. А то от флуда больше муторно, чем от кода. :)

 
ivandurak:

Можно чуть поправить.  Оптимизационные параметры записывать в структуры, а с ними (структуры  простые) работать как с переменными. Что то такое

if(!trpar && Par1==Parold1 && Par2==Parold2) { Parold1=Par; Parold2=Par2 ; return(9) }    Здесь Par и Parold структуры в которые пишутся оптимальные параметры с других валютных пар.

Ну да, что-то в этом роде. Просто получается, что нужно будет запоминать ВСЕ "рабочие наборы параметров", которые столкнулись с  trpar2=false. Т.е. массив соответствующих структур будет неимоверно расширяться. К тому его надо будет сохранять в файл, чтобы прочитать запомненное при новом проходе.
 
ivandurak:

Можно чуть поправить.  Оптимизационные параметры записывать в структуры, а с ними (структуры  простые) работать как с переменными. Что то такое

if(!trpar && Par1==Parold1 && Par2==Parold2) { Parold1=Par; Parold2=Par2 ; return(9) }    Здесь Par и Parold структуры в которые пишутся оптимальные параметры с других валютных пар. Сколько пар столько и ифов , выглядит не так уж безобразно. Спасибо.

Есть ещё один вариант (надо же, из головы вылетело).

Посмотрите функции: OnTesterInit(), OnTesterPass(), OnTesterDeinit()

И: FrameFirst(), FrameFilter(), FrameNext(), FrameInputs(), FrameAdd()

Они прямо для этого и предназначены. :)

То есть, всегда можно запросить все параметры любого прохода в текущей оптимизации в любой момент времени.

1...732733734735736737738739740741742743744745746...3588
Новый комментарий