ФорумРазделы

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

Новый комментарий
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()

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

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

tol64:

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

Я этим хотел сказать, что Ваша так называемая "элегантная" последняя строчка в блоке слежения совершенно не улучшает остальные 10500 возможных строчек этого самого блока. Если для Вас так принципиально использовать в int OnInit() функцию ExpertRemove()  вместо оператора return(-100), то это всего лишь Ваше предпочтение, никак не улучшающее весь остальной код.  

Напомню при этом: всё началось с Вашей фразы "Всё проще". В результате оказалось, что никакого упрощения нет, есть только возможная замена одной строчки кода на другую.

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