최적화 알고리즘 챔피언십. - 페이지 5

 
Andrey Dik :

간단한 예입니다. 최적화 알고리즘은 차트 어딘가에 있습니다. 그리고 표준 테스터에서 Expert Advisor의 최적화는 철저한 검색에 의해 시작되었습니다. 따라서 일반 알고리즘 대신 최적화 알고리즘을 사용할 수 있습니다.

다른 예시. EA는 차트 및 거래에서 작동합니다. 일정 시간 후 거래 결과를 해당 매개변수와 함께 알고리즘(어드바이저 내부 또는 외부에 있을 수 있음)에 던지고 새 매개변수를 다시 가져온 다음 거래를 계속합니다(귀하의 경우 다음을 실행해야 합니다. 하지만 제 경우에는 "라이브"를 선택할 수 있습니다.)

등. 즉, 이 예에서 알고리즘은 작업에서 완전히 분리됩니다.

예는 거래와 관련하여 의도적으로 제공되었습니다. 마우스 상인.

뭔가 이상합니다.

Expert Advisor의 최적화는 이미 테스터에서 시작되었지만 자체 최적화 알고리즘과 어떤 관련이 있습니까?

두 번째 경우는 조금 더 명확합니다. 예, 단일 독립 호출을 제공하는 경우 중간에 한 번 호출할 수 있습니다. 그리고 한번에 별도의 공정으로 가능합니다. 그것은 분명하지만 이것은 알고리즘의 복잡성이며 챔피언십 목표에서 벗어납니다. 챔피언십의 목표는 최적화 알고리즘이지 적용이 아닙니다. 여기저기서 얼마나 많은 사람들이 지나갔는지, 이해하지 못했는지, 그런 합병증이 있습니다.

 
Andrey Dik :

일반적으로 이와 같은 것이며 물론 시간 카운터가 있을 것입니다. 스케치:

이 코드에서는 일회성 호출이 아니지만 알고리즘의 주요 부분이 제거되고 알고리즘의 일부가 참가자에게 부과됩니다. 초기 조건에서 참가자는 전체 알고리즘을 숨길 권리가 있습니다.
 
Dmitry Fedoseev :

1. 일반적으로 초월적인 것. Expert Advisor의 최적화는 이미 테스터에서 시작되었지만 자체 최적화 알고리즘과 어떤 관련이 있습니까?

2. 두 번째 경우는 조금 더 명확합니다. 예, 단일 독립 호출을 제공하는 경우 중간에 한 번 호출할 수 있습니다. 그리고 한번에 별도의 공정으로 가능합니다. 분명하지만 이것은 알고리즘의 복잡성이며 챔피언십 목표에서 벗어납니다. 챔피언십의 목표는 최적화 알고리즘이지 적용이 아닙니다. 여기저기서 얼마나 많은 사람들이 지나갔는지, 이해하지 못했으며 그런 합병증이 있습니다.

1. 터무니없는 생활 상황은 없습니다. 일반 테스터는 차례로 실행하고(하나의 매개변수가 정렬됨 - 카운터) 모든 매개변수의 최적화를 무제한으로 제어합니다.

2. FF로 작업하기 위해 2가지 옵션을 사용하기로 결정했습니다. 따라서 모든 것이 잘되고 문제가 없습니다. 최적화를 사용하려는 사람은 누구든지 사용할 것입니다.

참가자는 첫 번째 또는 두 번째로 작업할 테스트 스크립트를 자유롭게 선택할 수 있습니다.

 
Dmitry Fedoseev :
이 코드에서는 일회성 호출이 아니지만 알고리즘의 주요 부분이 제거되고 알고리즘의 일부가 참가자에게 부과됩니다. 초기 조건에서 참가자는 전체 알고리즘을 숨길 권리가 있습니다.

부과금은 어디에 있습니까? 알고리즘은 몇 번이고 무엇을 계산할지 묻고 참가자 자신의 알고리즘이 그러한 것을 결정합니다. 결국 알고리즘은 동일한 GA의 아키텍처에서 크게 다를 수 있으며 예제를 통해 모든 작동 원리에서 알고리즘을 사용할 수 있습니다.

나는 거기에서 서비스 기능을 보여주었습니다. 참가자가 필요하지 않으면 비어있을 수 있습니다.

 
Andrey Dik :

부과금은 어디에 있습니까? 알고리즘은 몇 번이고 무엇을 계산할지 묻고 참가자 자신의 알고리즘이 그러한 것을 결정합니다. 결국 알고리즘은 동일한 GA의 아키텍처에서 크게 다를 수 있으며 예제를 통해 모든 작동 원리에서 알고리즘을 사용할 수 있습니다.

나는 거기에서 서비스 기능을 보여주었습니다. 참가자가 필요하지 않으면 비어있을 수 있습니다.

참가자에게 메서드가 있는 함수 또는 객체에 대한 포인터를 제공하기만 하면 됩니다. 세 번째 천년입니다.
 
또한, Epoch 수와 개인 수가 분산될 수 있도록 허용된 ff 호출 수를 멤버 함수에 전달합니다.
 
Dmitry Fedoseev :
또한, Epoch 수와 개인 수가 분산될 수 있도록 허용된 ff 호출 수를 멤버 함수에 전달합니다.

예를 들어 알고리즘은 최대 100 FF 실행이 가능하다고 들었습니다. 아하! - 그는 (알고리즘), 내가 모든 사람을 능가하고 50개의 음표에 대해 FF를 50 번만 호출할 것이라고 생각했습니다. :)

아니요, 그가 얼마나 필요한지 계산하게 하십시오. 그리고 언제 멈출지 결정할 것입니다. 결국 FF 출시 횟수는 작업 품질의 지표로 평가됩니다.

 
Andrey Dik :

예를 들어 알고리즘은 최대 100 FF 실행이 가능하다고 들었습니다. 아하! - 그는 (알고리즘), 내가 모든 사람을 능가하고 50개의 음표에 대해 FF를 50 번만 호출할 것이라고 생각했습니다. :)

아니요, 그가 얼마나 필요한지 계산하게 하십시오. 그리고 언제 멈출지 결정할 것입니다. 결국 FF 출시 횟수는 작업 품질의 지표로 평가됩니다.

그렇게 교활하고 전화를 덜 받는 게 무슨 소용이야? 더 적은 것은 가능하고 더 많은 것은 불가능합니다. 문제가 무엇입니까?

ff 함수는 호출을 계산합니다. 허용보다 많은 경우 - 실격.

 

다음은 회원 라이브러리 템플릿입니다.

 #property library
#property copyright "Copyright 2016, MetaQuotes Software Corp."
#property link        "https://www.mql5.com"
#property version    "1.00"
#property strict

class CFF{
   public :
   virtual double fun( double & x[]){ return ( 0 );}
   virtual string type(){ return ( "" );}
   virtual double value(){ return ( 0 );}
   virtual string note(){ return ( "" );}
};

здесь участник пишет свои классы, если надо 

void function(CFF * aff, int n, double & params[], double & value) export {

    Здесь участник пишет свой код и вызывает функцию так - aff.value(x); // x - это массив double

//по окончанию поиска вернуть params (параметры соответствующие лучшему результату), value (лучший результат)

}

здесь участник создает свои вспомогательные функции
 
Dmitry Fedoseev :

그렇게 교활하고 전화를 덜 받는 게 무슨 소용이야? 더 적은 것은 가능하고 더 많은 것은 불가능합니다. 문제가 무엇입니까?

ff 함수는 호출 수를 계산합니다. 허용보다 많은 경우 - 실격.

FF 시작 횟수는 적을수록 좋습니다. 그게 요점입니다. 이것은 까다로울 수 있습니다.

알고리즘을 제한할 필요가 없습니다. 그는 멈춰야 한다고 결정하거나 강제로 멈출 것입니다. 얼마나 많은 상한선을 발사하는지 - 알고리즘은 아무도 모를 상한선을 알 수 없습니다. 결격사유가 없을 것입니다. 알고리즘이 할 수 있는 대로 문제가 해결될 것입니다.

실격의 유일한 이유는 결과를 저장하고 테스트 스크립트의 후속 실행에 사용하려는 시도입니다.