최적화 결과의 자동 선택 기준입니다. - 페이지 6

 
Figar0 >> :

저것들. 내가 올바르게 이해한다면 결과가 아니라 트랜잭션의 품질을 평가하는 방법은 트랜잭션이 시스템에 포함된 것과 어느 정도 일치합니까?

머리로 돌려야 합니다.

일반적으로 그렇습니다. 가장 중요한 것은 거래의 그림이 가능한 한 많이 보이는 것입니다. 필터가 위험한 거래를 통과하도록 허용하더라도 어떻게든 표시하고 트리거 가능성이 무엇인지 확인해야 합니다. 필터가 주 신호의 반경에 더 가깝게 트리거할 확률로 위험을 제거하면 미래에 이러한 필터가 대체됩니다. 그리고 그것이 수익성 있는 것의 많은 부분을 먹어치우면 나쁘다. 열려는 신호의 가장 가까운 반경에 있는 모든 것을 열고 유지하려고 하는 것이 더 쉽습니다. 가장 중요한 것은 반경을 명확하게 정의하는 것입니다.

 

TS가 수익성이 좋고 모든 가능한 거래가 열리고 하락만 그림을 망칠 경우이 질병에 대한 치료법도 있습니다 ...

가장 중요한 것은 모든 거래가 눈앞에 있다는 것입니다 ...

 
그건 그렇고, 여기 에 주제에 대한 내 생각이 있습니다 ...
 

우리는 존경합니다, 우리는 존경합니다...


내가 준 공식은 비례적으로 증가하는 부지에만 적용할 수 있다는 것을 잊어버렸습니다.

 
ivandurak >> :
А как же распределение результатов сделок . Львиная доля прибыли может быть и в начале исследуемого периода .

좋아요. 우리는 틱 시간이 아닌 천문학적 시간으로 거래합니다. 거래 수에 비례하여 구축된 Expert Advisor는 거의 완벽한 직선을 보일 수 있지만, 가볍게 말해서 "별로 그렇지는 않습니다." 모든 이익의 절반은 처음에 처음 100개의 거래에서 이루어졌으며 첫 해와 하반기 - 지난 100년 동안, 그러나 이미 5년 동안(성공적인 거래의 수가 거의 같기 때문에 동일한 기울기로 직선). 기간 자체에 대한 시스템의 상대적 이익 의존도와 같은 형식화에 대해 생각해 봅시다.

물론 단일 최적화 기준은 없으며 그럴 수도 없습니다. 글쎄요, 공식적으로는 수십 가지의 이질적인 기준으로 구성될 수 있습니다. 하지만 그것이 무슨 소용이겠습니까?

 
Mathemat >> :


물론 단일 기준은 없으며, 있을 수도 없습니다. 글쎄요, 공식적으로는 수십 가지의 이질적인 기준으로 구성될 수 있습니다. 하지만 그것이 무슨 소용이겠습니까?

Mathemat, 매개변수에 어떤 임계값을 적용해야 하는지 알 수 있습니까? 예를 들어, 통합 지표를 사용하여 필터링을 처리하기 전에 1년 동안 최적화를 통해 트랜잭션 수, 수학적 기대 및 수익성과 같은 매개변수를 적용해야 합니까? 예를 들어, 결과를 훑어본 후: 거래 < 50; 기대치 < 50 및 수익성 < 2 임의의 스트레이 또는 클러스터가 남아 있지만 이제는 구름이라고하는 것이 유행입니다. 클라우드에서 기계가 Profit * Profit / Drawdown(%)이 더 많은 사람을 스스로 선택하도록 허용했습니다.

거래 건수, 기대치, 올해 최적화 시 수익성에 따른 사전 심사에 대한 전문가의 의견이 궁금합니다.

 

Vita писал(а) >> Я, к примеру, после отметания результатов: сделок < 50; матожидание < 50 и прибыльность < 2 не испытываю пробелемы выбора среди тысячи результатов, т.к. остаются либо случайные залетные, либо кластер, но нынче модно говорить облако. Из облака я для себя позволил автомату выбирать у кого больше Прибыль * Прибыльность / Просадка в % .

Vita , 일반적으로 원칙적으로. 사전 심사 - 거래 건수 기준 m.o. 및 PF 및 최종 선별 - "흐림"과 함께 꽤 괜찮은 통합 기준에 따릅니다. 저것들. 실제로 전체 절차에는 약 5가지 기준으로 필터링하는 작업이 포함됩니다.

사전 심사 숫자 자체 (m.o., 나는 오래된 본격적인 지점에서, 즉 4 자리 숫자로?)는 매우 논리적입니다. 결과의 통계적 신뢰도를 높이려면 최소 거래 수(예: 200개)를 늘릴 것입니다.

 

그건 그렇고, 여기 에 흥미로운 기사가 있습니다. 회귀 이론이 마음에 들었습니다. 구현할 가치가 있습니다 ...

이익 * 이익 / 손실(%) . 이것도 좋지만 테스트 기간이 이익 지표에 영향을 미치지 않도록 1일 이익 비율(잔액에 비례하여 증가하는 로트의 경우) 또는 1일 이익 지표( 고정 로트용). 누군가가 하루에 백분율을 계산하는 방법을 모른다면 다음 공식을 제안합니다.

Pr - 하루/거래당 백분율

Days_Sdelki - 일 또는 거래 수(계산 목적, 거래 비율 또는 일일 비율에 따라 다름)

Bal_begin - 기간 시작 시 잔액

Bal_end - 기간 말의 잔액

Pr=(MathExp(((1/Days_Sdelki)*(MathLog(Bal_end/Bal_begin))))-1)*100;

 

또는 여기 기능이 있습니다


더블 퍼센트(더블 Days_Sdelki, 더블 Bal_begin, 더블 Bal_end)
{
if(Days_Sdelki>1 && Bal_begin!=0) return((MathExp(((1/Days_Sdelki)*( MathLog (Bal_end/Bal_begin))))-1)*100);
그렇지 않으면 반환(0);
}

 

하나의 유용한 변수를 도입했으며 내 공식의 새 버전을 테스트하고 있습니다.


PipBar - 핍/바(모든 거래에 대한 핍 합계를 이 경우 사용한 막대의 양으로 나눈 값)

PF - 수익성(이익 계수)

SdDay - 하루 거래 수

ProcDay - 하루 수익 비율(로그가 있는 복잡한 공식)

MD - 최대 드로다운

SrD - 평균 하락(각 주문의 하락 합계를 주문 수로 나눈 값)


if(PF>3) Vigoda=2*SdDay+(PipBar/10)+(10*(ProcDay/((MD+SrD)/10)));
else Vigoda=(PF-1)*SdDay+(PipBar/10)+(10*(ProcDay/((MD+SrD)/10)));


지금까지는 테스트 버전이지만 지표는 이미 만족 ...