그리고 "과소 테스터"에서 완전한 열거에 10시간이 걸리고 MT에서 몇 개월이 걸리는 알고리즘의 예를 들 수 있습니까?
최적화에서 완전한 검색이 발견적 방법보다 빠를 때도 상황은 현실적입니다. MT의 전체 검색은 서로 독립적인 실행 집합으로 표시됩니다. 실제로 최적화를 하나의 단일 계산 문제로 간주하고 이에 알고리즘 최적화를 적용하는 것은 항상 가능합니다.
이 접근 방식을 사용하면 거의 모든 계산이 캐시되기 때문에 패스 시퀀스가 매우 중요합니다. 옵티마이저의 거의 모든 (모든 독립적인) TS 입력 매개변수에는 항상 이전 패스의 값을 저장하는 전역 버퍼가 있습니다.
예를 들어, Mashka 및 PriceChannel을 사용하고 있습니다. 이러한 표시기 각각에는 자체 독립 입력 매개변수가 있습니다. 따라서 각 표시기에 대해 해당 전역 버퍼를 채우는 기능이 규정되어 있습니다(몇 줄, 실제로 OOP를 사용하면 훨씬 더 아름다워야 함). 다음으로 각 지표의 자원 집약도를 비교합니다(PriceChannel이 Mashka보다 무겁습니다). 가장 무거운 표시기의 입력 매개변수는 외부 윤곽선(첫 번째 for)에서 열거되기 시작하는 반면, 가장 단순한 표시기의 입력 매개변수는 내부 윤곽선(중첩 for)으로 전달되기 시작합니다.
여기서 큰 승리가 나옵니다. 플러스 C ++, 정수 계산 및 불필요한 확인 없이 자체 주문 시스템. 이것이 결과를 얻는 방법입니다. 결과적으로 단일 실행은 MT보다 적어도 10배 더 빠릅니다. 그리고 최적화 - 이미 엄청난 규모입니다.
MT 옵티마이저에는 최적화 결과의 결과 매트릭스에 대한 전체 액세스 권한이 있는 OnOptimization 기능이 없습니다. 거기에서 결과 매트릭스에 대한 다양한 분석을 수행합니다. 필터링, 거래 시간 측면에서 교차하지 않는 TS의 구절을 결합하는 등 그러나 더욱 유용한 것은 해당 포트폴리오의 형태로 meta-TC를 구성하기 위해 각 패스에 대한 가중치를 계산하는 것입니다. 이를 위해 OnOptimization에는 희망이 없는 각 패스에 대한 Equity-vector가 있습니다.
그러나 손은 작동 차량을 찾는 단계가 아니라 불행히도 이미 발견되었을 때 언더 테스터에게 도달합니다. 검색 자체는 설명이 없는 완전히 다른 단계입니다.
예를 들어, Mashka 및 PriceChannel을 사용하고 있습니다. 이러한 표시기 각각에는 자체 독립 입력 매개변수가 있습니다. 따라서 각 표시기에 대해 해당 전역 버퍼를 채우는 기능이 규정되어 있습니다(몇 줄, 실제로 OOP를 사용하면 훨씬 더 아름다워야 함). 다음으로 각 지표의 자원 집약도를 비교합니다(PriceChannel이 Mashka보다 무겁습니다). 가장 무거운 표시기의 입력 매개변수는 외부 윤곽선(첫 번째 for)에서 열거되기 시작하는 반면, 가장 단순한 표시기의 입력 매개변수는 내부 윤곽선(중첩 for)으로 전달되기 시작합니다.
이 접근 방식이 GA로 쉽게 구현될 수 있다는 말이 있습니다. 작업량은 거의 같습니다. "내부 루프"는 모든 패스에서 반복됩니다...
그러나 가장 중요한 것은 수요가 얼마나 될까요? 내가 생각하는 것처럼 사용자 정의 OnTester() 함수조차도 모든 사람이 사용하는 것은 아닙니다. 그러나 이것은 매우 강력한 최적화 도구입니다.
두 개의 짝수 최대값 고원을 포함하는 함수에 대한 또 다른 테스트를 추가하겠습니다.
z = abs(tanh(x) + tanh(y))
0.1 단계로 X,Y를 -20에서 +20으로 변경할 때 전체 열거는 160801번 반복됩니다.
테스트에서 두 고원은 1400회 반복에서 볼 수 있으며 이는 전체 검색의 1% 미만입니다.
누구든지 GA에서 이것을 실행합니까? 비교하는 것이 흥미롭습니다.
두 개의 짝수 최대값 고원을 포함하는 함수에 대한 또 다른 테스트를 추가하겠습니다.
z = abs(tanh(x) + tanh(y))
0.1 단계로 X,Y를 -20에서 +20으로 변경할 때 전체 열거는 160801번 반복됩니다.
테스트에서 두 고원은 1400회 반복에서 볼 수 있으며 이는 전체 검색의 1% 미만입니다.
누구든지 GA에서 이것을 실행합니까? 비교하는 것이 흥미롭습니다.
GA를 찾고 있지 않습니까?
최적화되는 함수의 두 인수로 작업하는 것은 전혀 지표가 아닙니다. 검색 공간이 작을 뿐만 아니라 검색 알고리즘 자체의 "나쁜" 속성이 나타날 수 있기 때문입니다.
최소 10개의 인수가 있는 형식으로 수식을 변환하십시오. 알고리즘의 모든 긍정적이고 부정적인 속성이 즉시 나타납니다.
GA를 찾고 있지 않습니까?
최적화되는 함수의 두 인수로 작업하는 것은 전혀 지표가 아닙니다. 검색 공간이 작을 뿐만 아니라 검색 알고리즘 자체의 "나쁜" 속성이 나타날 수 있기 때문입니다.
최소 10개의 인수가 있는 형식으로 수식을 변환하십시오. 알고리즘의 모든 긍정적이고 부정적인 속성이 즉시 나타납니다.
이것은 GA가 아니며 스레드에 기사에 대한 링크가 있습니다.
위에는 6개의 매개변수가 있는 예가 나와 있습니다. 많은 매개변수의 표시로 인한 모든 복잡성.
많은 수의 매개변수가 있는 함수를 제공하면 테스트를 수행하겠습니다.
많은 수의 매개변수가 있는 함수를 제공하면 테스트를 수행하겠습니다.
Y=a+b;
어디:
a=스킨(x1, y1)+스킨(x2, y2)+스킨(x3, y3)+스킨(x4, y4)+스킨(x5, y5);
b=스킨(x6, y6)+스킨(x7, y7)+스킨(x8, y8)+스킨(x9, y9)+스킨(x10, y10);
Skin 기능을 찾을 위치를 이미 알고 있습니다.
그리고 20개의 변수와 Y 함수는 시각화하기가 매우 쉽습니다. 이 원칙에 따르면 무제한의 인수로 함수를 작성할 수 있지만 동시에 시각화할 수 있습니다.
따라서 최종 결과는 알려진 극한값과 비교하여 Y*2/n으로 확인됩니다. 여기서 n은 총 인수 수입니다.
그리고 "과소 테스터"에서 완전한 열거에 10시간이 걸리고 MT에서 몇 개월이 걸리는 알고리즘의 예를 들 수 있습니까?
이 접근 방식을 사용하면 거의 모든 계산이 캐시되기 때문에 패스 시퀀스가 매우 중요합니다. 옵티마이저의 거의 모든 (모든 독립적인) TS 입력 매개변수에는 항상 이전 패스의 값을 저장하는 전역 버퍼가 있습니다.
예를 들어, Mashka 및 PriceChannel을 사용하고 있습니다. 이러한 표시기 각각에는 자체 독립 입력 매개변수가 있습니다. 따라서 각 표시기에 대해 해당 전역 버퍼를 채우는 기능이 규정되어 있습니다(몇 줄, 실제로 OOP를 사용하면 훨씬 더 아름다워야 함). 다음으로 각 지표의 자원 집약도를 비교합니다(PriceChannel이 Mashka보다 무겁습니다). 가장 무거운 표시기의 입력 매개변수는 외부 윤곽선(첫 번째 for)에서 열거되기 시작하는 반면, 가장 단순한 표시기의 입력 매개변수는 내부 윤곽선(중첩 for)으로 전달되기 시작합니다.
여기서 큰 승리가 나옵니다. 플러스 C ++, 정수 계산 및 불필요한 확인 없이 자체 주문 시스템. 이것이 결과를 얻는 방법입니다. 결과적으로 단일 실행은 MT보다 적어도 10배 더 빠릅니다. 그리고 최적화 - 이미 엄청난 규모입니다.
MT 옵티마이저에는 최적화 결과의 결과 매트릭스에 대한 전체 액세스 권한이 있는 OnOptimization 기능이 없습니다. 거기에서 결과 매트릭스에 대한 다양한 분석을 수행합니다. 필터링, 거래 시간 측면에서 교차하지 않는 TS의 구절을 결합하는 등 그러나 더욱 유용한 것은 해당 포트폴리오의 형태로 meta-TC를 구성하기 위해 각 패스에 대한 가중치를 계산하는 것입니다. 이를 위해 OnOptimization에는 희망이 없는 각 패스에 대한 Equity-vector가 있습니다.
그러나 손은 작동 차량을 찾는 단계가 아니라 불행히도 이미 발견되었을 때 언더 테스터에게 도달합니다. 검색 자체는 설명이 없는 완전히 다른 단계입니다.
누구든지 GA에서 이것을 실행합니까? 비교하는 것이 흥미롭습니다.
Y=a+b;
어디:
a=스킨(x1, y1)+스킨(x2, y2)+스킨(x3, y3)+스킨(x4, y4)+스킨(x5, y5);
b=스킨(x6, y6)+스킨(x7, y7)+스킨(x8, y8)+스킨(x9, y9)+스킨(x10, y10);
Skin 기능을 찾을 위치를 이미 알고 있습니다.
20개의 변수와 Y 함수는 시각화하기가 매우 쉽습니다. 이 원칙에 따르면 무제한의 인수로 함수를 작성할 수 있지만 동시에 시각화할 수 있습니다.
따라서 최종 결과는 알려진 극한값과 비교하여 Y*2/n으로 확인됩니다. 여기서 n은 총 인수 수입니다.
얼마나 많은 패스와 변수 계산 단계가 있습니까?
사진이 마음에 들지 않으면 무슨 차이가 있습니까?
MT5의 64비트 GA는 매우 훌륭하며 모든 문제를 해결합니다. 가장 중요한 것은 문제를 올바르게 공식화하는 것입니다.
그리고 속도 면에서 그는 동등하지 않습니다. 이 스레드에서 GA에 대한 대화를 시작하게 된 계기가 이해가 되지 않습니다.
문제는 GA에 전혀 없지만, 특히 증권 거래소에서 테스터 자체가 쓸모가 없다는 사실에 있습니다. 시세 이력의 잘못된 저장과 이력을 슬립할 수 없기 때문입니다.
이 문제가 해결되기를 바랍니다. 3~5년은 기다려야 합니다.
예를 들어, Mashka 및 PriceChannel을 사용하고 있습니다. 이러한 표시기 각각에는 자체 독립 입력 매개변수가 있습니다. 따라서 각 표시기에 대해 해당 전역 버퍼를 채우는 기능이 규정되어 있습니다(몇 줄, 실제로 OOP를 사용하면 훨씬 더 아름다워야 함). 다음으로 각 지표의 자원 집약도를 비교합니다(PriceChannel이 Mashka보다 무겁습니다). 가장 무거운 표시기의 입력 매개변수는 외부 윤곽선(첫 번째 for)에서 열거되기 시작하는 반면, 가장 단순한 표시기의 입력 매개변수는 내부 윤곽선(중첩 for)으로 전달되기 시작합니다.
이 접근 방식이 GA로 쉽게 구현될 수 있다는 말이 있습니다. 작업량은 거의 같습니다. "내부 루프"는 모든 패스에서 반복됩니다...
그러나 가장 중요한 것은 수요가 얼마나 될까요? 내가 생각하는 것처럼 사용자 정의 OnTester() 함수조차도 모든 사람이 사용하는 것은 아닙니다. 그러나 이것은 매우 강력한 최적화 도구입니다.
예를 들어 다음은 내 구현 중 하나입니다.
double CDoublePeakBottomAdvisorPartsFactory::MyOnTester(CMyExpertT* pmeExpert)
{
ulong ulTickedTime = pmeExpert.GetTickedTime();
uint uiTotalNumberOfSL = pmeExpert.GetNumOfLosePositions();
double dDDPercent = TesterStatistics(STAT_EQUITY_DDREL_PERCENT);
double dStartBalance = TesterStatistics(STAT_INITIAL_DEPOSIT);
double dProfit = TesterStatistics(STAT_PROFIT);
double dNumOfTrades = TesterStatistics(STAT_TRADES);
double dNumOfProfitTrades = TesterStatistics(STAT_PROFIT_TRADES);
double dMaxNumOfSL = TesterStatistics(STAT_MAX_CONLOSS_TRADES);
double dRecoveryFactor = TesterStatistics(STAT_RECOVERY_FACTOR);
double dProfitTradesPerWeek = dNumOfProfitTrades/ulTickedTime*SECS_IN_WEEK;
double dProfitPerDay = dProfit/ulTickedTime*SECS_IN_DAY;
Print("Ticked time (days): ",DoubleToString(ulTickedTime/SECS_IN_DAY,2));
Print("Number Of Trades: ",DoubleToString(dNumOfTrades,1));
if(dNumOfTrades == 0)
{
Print("Ни одного трейда !");
return(-100000);
};
if(dMaxNumOfSL > uiIMaxNumOfSeqSL)
return(-10000 - dMaxNumOfSL*100 + dProfit/1000);
double dBarsPerTrade = ((double)ulTickedTime/PeriodSeconds(m_didData.m_etTimeFrame))/dNumOfTrades;
if((bILongAllow == false) || (bIShortAllow == false))
dBarsPerTrade /= 2;
if(dBarsPerTrade < MIN_BARS_PER_TRADE)
return(dBarsPerTrade-MIN_BARS_PER_TRADE + dRecoveryFactor);
Print("Max number Of SL: ",DoubleToString(dMaxNumOfSL,1));
if(iIMaxNumOfSeqSLForQualify > 0 && dMaxNumOfSL > iIMaxNumOfSeqSLForQualify)
{
Print("Слишком много СЛ подряд !");
return(dRecoveryFactor - (dMaxNumOfSL-iIMaxNumOfSeqSLForQualify)*1000)-10000;
};
Print("Bars Per Trade (half): ",DoubleToString(dBarsPerTrade,1));
if(dBarsPerTrade > MAX_BARS_PER_TRADE)
{
Print("Слишком редкие трейды !");
return(dRecoveryFactor - dBarsPerTrade/100);
};
Print("Profit: ",DoubleToString(dProfit,3));
Print("Profit per day: ",DoubleToString(dProfitPerDay,3));
Print("Число СЛ: ",IntegerToString(uiTotalNumberOfSL));
Print("Приемлемая торговля.");
return(dRecoveryFactor + (1-(uiTotalNumberOfSL/dNumOfTrades))*100);
};
여기서 기본은 회복 요인이지만 최소 SL 수로 연속적으로 실행되고 상당히 빈번한 거래가 두드러집니다.
그러나 내가 볼 수 있듯이 대부분은 표준 옵션을 사용합니다.