Vladimir Baskakov : 나는 여전히 100% 자동화의 지지자입니다. 수동으로 다시 최적화하는 방법을 이해하지 못합니까? 그러면 좋지 않다.
반. 특수 스크립트는 재 최적화가 필요한 시스템을 선택하고 설정 파일을 준비합니다. 다음으로 다른 스크립트는 옵티마이저를 통해 모든 시스템을 실행합니다. 세 번째 스크립트는 최적화 결과를 기반으로 최상의 패스를 선택하고 시스템 구성 절차 텍스트로 파일을 준비합니다. 이 텍스트를 TS 클래스로 전송하고(저는 아직 전체 시스템을 신뢰하지 않으며 여기에서 프로세스를 완전히 제어합니다.) 그런 다음 실행 모듈이 다시 컴파일되고 VPS에서 업데이트되고 다음 날 프로세스가 반복됩니다.
반. 특수 스크립트는 재 최적화가 필요한 시스템을 선택하고 설정 파일을 준비합니다. 다음으로 다른 스크립트는 옵티마이저를 통해 모든 시스템을 실행합니다. 세 번째 스크립트는 최적화 결과를 기반으로 최상의 패스를 선택하고 시스템 구성 절차 텍스트로 파일을 준비합니다. 이 텍스트를 TS 클래스로 전송하고(저는 아직 전체 시스템을 신뢰하지 않으며 여기에서 프로세스를 완전히 제어합니다.) 그런 다음 실행 모듈이 다시 컴파일되고 VPS에서 업데이트되고 다음 날 프로세스가 반복됩니다.
2. 우리는 모든 XXX 시스템에서 가상으로 거래하고, 지표를 평가하고, 실시간 인출을 위해 몇 가지를 선택하고, 이미 실제 거래를 엽니다.
가상 환경을 귀찮게 하고 싶지 않다면(기성품 fxsaber가 있지만) 통계를 위해 0.01랏을, 결과를 위해 1.00랏을 거래할 수 있습니다.
앉아서 데모를 볼 필요가 없습니다. 모든 것이 즉시 명확해질 것입니다.
1. 여기 이 차량의 경우 - 가능합니다. 항상 "최상의 시스템을 자동으로 선택하고 교환"하는 것은 아닙니다. 차량 매개변수의 평균값이 몇 가지 있는데, 선택하는 것이 프로그래밍하기 쉽지 않은 경우 각 "중간" 매개변수 값과 선택한 모든 "중간" 매개변수 값에 대해 결과를 확인해야 합니다. 이러한 캠페인을 통해 더 이상 "최고의 시스템을 자동으로 선택하고 이를 거래하는 것"이 아니라 더 신뢰할 수 있다고 생각합니다.
2. 절대적으로 사실입니다. 완전히 동의 해. 나 자신도 이 접근 방식을 귀찮게 할 것입니다. TC는 아직 이 테스트를 할 준비가 되지 않았습니다...
2016년부터... :-) 특별히 복잡한 것은 없지만 모든 것을 쓰지는 않았습니다. 어리석게도 시간이 없습니다. 일용할 양식에 대한 관심과 TS의 다른 개발은 이 방향으로 무한한 창의성에 참여하는 것을 허용하지 않습니다.
최고의 시스템을 선택하는 것은 마지막으로 해결되지 않은 문제입니다. "순전히 최고"를 취하는 것은 불가능합니다. 당신은 최고의 결과를 보여주었던 시스템을 가져갔고, 그것은 꽝 - 그리고 작동을 멈췄습니다. 테스트를 한 것 같고 이미 데모에서 12개 이상의 성공적인 거래를 보여주긴 했지만... 하지만, 밝혀진 바에 따르면 안정성이 없습니다... 그래서 차트를 보고 선택하고, 비교하고, 추정합니다. 원칙 자체의 성능... 그리고 결과적으로 실제 시스템을 설정하는 것은 공식보다 훨씬 더 직관적입니다. 그것을 인코딩하는 방법?
그리고 가상 환경은 어떻습니까? 모든 시스템을 데모에 넣을 수 있고 당신이 올바르게 제안한 대로 "통계를 위해 0.01 랏을 거래"할 수 있다면 강력한 컴퓨터와 함께 강력한 컴퓨터를 사용하는 것이 무슨 의미가 있습니까? 그래요. 나는 다락방에 2개의 터미널이 있는 오래된 컴퓨터를 가지고 있으며, 그것은 TS 리그의 중하위 부서를 운영합니다. 맨 위 디비전 - UPU에 있습니다 (우리는 종종 조명을 끄므로 맨 위 디비전의 경우 사용해야 함).
사실 내 TS 리그는 자동 모드에서 시스템을 지속적으로 테스트하는 "가상 환경"이기도 합니다. 여기 - 모든 것이 이미 해결되었으며 제어 매개 변수의 경우 재설치 절차도 이미 표준적이고 일상적입니다.
문제는 가장 안정적인 것을 선택하는 것입니다. 저는 "품질" 매개변수가 정말 마음에 들었습니다. 우리는 그것을 공식화했습니다. 그러나 매개 변수 "안정성"은 나에게 적합하지 않습니다. 이것은 기본적으로 내가 지금 작업하고 있는 것입니다.
:-) 테스트 및 매개 변수 선택 후 값의 의미에서 즉시 실제와 전투에 참여합니다. 당신은 그것을 실제의 데모에서 넣었습니다. 너무 늦게, 실제에서 제거하고 매개변수 값을 다시 최적화할 시간입니다...
실제 작업 시간은 물론 테스트의 20%-30%이며 트랜잭션 및 테스트 시간에 대한 명확한 테스트 샘플이 있습니다.
IMHO, 이 접근 방식은 올바르지 않습니다. " 이 날짜 이전에 2년 간의 테스트가 수행되고, 1년은 뒤로, 1년은 앞으로입니다. 이 날짜 이후 - TS가 데모에 설치되고 최고의 데모 시스템의 결과를 게시합니다." p.62에서.
더 나아가 그것은 이미 분명하며 리그는 테스터에서 직접 최고의 차량을 선택할 수 있습니다(또는 스크립트와 테스터의 도움으로). 그러나 처음에는 선택 알고리즘을 테스터에 망치기 전에 발명해야 합니다! 즉, 적어도 "잡을" 것입니다. 어떻게 든 테스터에서 볼 수 있도록 가장 좋은 것을 강조 표시합니다. 이 알고리즘을 사용하여 시스템을 선택하면 더 나아가 안정적으로 작동합니까? 그리고 이것은 아닙니다!
여기에서 나는 공유 프로젝트를 위한 리그를 준비할 것입니다. 다시 바로 이 선택 알고리즘에서 실험을 할 것입니다.
그리고 "데모가 필요하지 않습니다"에 대해 - 동의하지 않습니다. 시스템의 안정성을 보려면 데모가 필요합니다 . 시스템이 테스터에서 작동하고 계속 작동하는지 확인하십시오.
나는 당신이 무덤에서 뼈를 일으킨 것을 계산하지 말라고 요청합니다. Robert Pardo의 링크에서 보십시오. 그는 최적화 및 기타 모든 것에 대한 모든 것을 능숙하게 그립니다.
:-) 테스트 및 매개 변수 선택 후 값의 의미에서 - 즉시 실제와 전투에 참여합니다. 당신은 그것들을 실제에서, 늦게, 너무 늦게 실제에서 그것들을 제거하고 매개변수 값을 다시 최적화할 시간입니다...
실제 작업 시간은 물론 테스트의 20%-30%이며 트랜잭션 및 테스트 시간에 대한 명확한 테스트 샘플이 있습니다.
IMHO, 이 접근 방식은 올바르지 않습니다. " 이 날짜 이전에 2년 간의 테스트가 수행되고, 1년은 뒤로, 1년은 앞으로입니다. 이 날짜 이후 - TS가 데모에 설치되고 최고의 데모 시스템의 결과를 게시합니다." p.62에서.
데모 계정은 더 이상 "차량 추가 확인"을 위해 필요하지 않습니다(이것도 역할을 하지만). 데모 계정의 주요 임무는 좋은 거래 내역을 보여주는 시스템의 지속적인 존재 인 "TC 풀"입니다.
"실제 테스트의 20 %의 작업 시간"에 관해서는-이것은 양날의 검입니다. 즉, 2 년의 테스트 후 차량의 작동 시간이 최대 5 개월임을 의미하기 때문입니다. 또한 2년 테스트를 위한 6개월 데모 테스트, 우리는 이미 차량의 작동 시간이 최대 7개월입니다. 이는 눈에 띄게 더 길었습니다.
실제로 데모 계정의 존재는 - 아무 것도 변경하지 않습니다. 글쎄, 나는 데모 계정이 없을 것이고, 나는 실제에 즉시 베팅할 것입니다 - 그러나 질문은 동일하게 유지됩니다. 수백 대의 Top Division 차량 중 어느 것을 넣어야 할까요? ?
1. "차량 추가 확인"을 위해 데모 계정이 더 이상 필요하지 않습니다(이것도 역할을 하지만). 데모 계정의 주요 임무 는 좋은 거래 내역을 보여주는 시스템의 지속적인 존재인 "TC 풀"입니다.
2. "실제 근로시간은 시험의 20%다" - 양날의 검이라 2년의 시험 후 차량 운행시간이 최대 5개월이라는 의미이기 때문에, 2년 테스트를 위한 6개월 데모 테스트가 있는 경우 이미 최대 7개월의 차량 작동 시간이 있습니다. 이는 눈에 띄게 더 긴 것입니다.
3. 정말, 데모 계정의 존재 - 아무 것도 변경되지 않습니다. 음, 저는 데모 계정이 없을 것입니다. 즉시 실제에 베팅할 것입니다. 놓다?
1. 이해할 수 있다. 내가 이해하는 한, 당신은 거기에 모든 비용을 청구했고 최종 자금은 빨간색으로 표시되어 있습니다.
2. 그렇지 않습니다. 최적화 시간은 2년입니다. 차량의 작동 시간은 최대 5개월입니다. 또한, 이것은 데모용 반기 테스트가 아니며 이미 입찰하고 모든 테스트가 끝났습니다.
"그리고 데모를 위한 6개월 테스트가 있습니다. 그러면 우리는 이미 차량의 작동 시간이 최대 7개월입니다. 이는 눈에 띄게 더 길어집니다." - 아니요, 시장 업데이트를 위한 매개변수를 다시 최적화해야 합니다. 일반적으로 ATP 값과 같이 적응력을 갖는 것이 바람직합니다 ...
R. Pardo는 혼자 전문가가 아니지만 다른 출처와 MKL4 포럼에 대한 더 많은 토론을 기반으로 이 접근 방식이 고려되고 있습니다.
유전 알고리즘에 따라 매개변수가 최적화된 경우 최상의 모델 매개변수 값을 결정해야 합니다.
여기에서 매개 변수 값의 완전한 열거가 있기 때문에 어리석게도 최선을 취했습니다.
예를 들어 최적화 - 4년입니다. 앞으로 테스트 0.5년. 4의 0.5g은 12.5%입니다. 또한 반년의 시간 이동으로.
또한, 최상의 "모델"에 대한 매개변수를 선택하기 위한 특정 알고리즘을 사용하여 여러 최적화에 대한 전방 분석의 끝, 예를 들어 귀하와 같은 다음(극단적인) 최적화 후 2년 동안은 이미 없습니다. 분기당 포워드 테스트, 그러나 이미 거래 중이거나 실제 또는 데모에서 거래할 계정에 대한 귀하와 같은 시스템에 약간의 차이가 있는 경우.
3. 여기 예 ... 여기에서 결정해야합니다 ... :-) (생각이 있습니다-조금 후에 IMHO를 쓸 것입니다 ...)
여기에 재 최적화가 필요한 차량 중 다소 유망한 차량도 있었는데 즉시 탑 디비전으로 갈 것입니다.
TS 242250 - GBPJPY의 EMATrendSAR. 2년 간의 역사는 97%의 품질, 실험적 안정성 평가 - 최대 47%를 보여줍니다(많은, 말 그대로 100대의 차량 중 1대가 40% 이상의 안정성을 가짐).
이 시스템의 이익 계수는 2.2이고 연간 9.1의 회수율이 있습니다. 사실, SL의 최대 대기열은 길고 - 5이고 최대 가격 하락 은 거의 8,000 세 자리 포인트입니다. 그러나 그녀가 어떻게 행동하는지 봅시다.
나는 여전히 100% 자동화의 지지자입니다. 수동으로 다시 최적화하는 방법을 이해하지 못합니까? 그러면 좋지 않다.
반. 특수 스크립트는 재 최적화가 필요한 시스템을 선택하고 설정 파일을 준비합니다. 다음으로 다른 스크립트는 옵티마이저를 통해 모든 시스템을 실행합니다. 세 번째 스크립트는 최적화 결과를 기반으로 최상의 패스를 선택하고 시스템 구성 절차 텍스트로 파일을 준비합니다. 이 텍스트를 TS 클래스로 전송하고(저는 아직 전체 시스템을 신뢰하지 않으며 여기에서 프로세스를 완전히 제어합니다.) 그런 다음 실행 모듈이 다시 컴파일되고 VPS에서 업데이트되고 다음 날 프로세스가 반복됩니다.
반. 특수 스크립트는 재 최적화가 필요한 시스템을 선택하고 설정 파일을 준비합니다. 다음으로 다른 스크립트는 옵티마이저를 통해 모든 시스템을 실행합니다. 세 번째 스크립트는 최적화 결과를 기반으로 최상의 패스를 선택하고 시스템 구성 절차 텍스트로 파일을 준비합니다. 이 텍스트를 TS 클래스로 전송하고(저는 아직 전체 시스템을 신뢰하지 않으며 여기에서 프로세스를 완전히 제어합니다.) 그런 다음 실행 모듈이 다시 컴파일되고 VPS에서 업데이트되고 다음 날 프로세스가 반복됩니다.
1. 최고의 시스템을 자동으로 선택하여 거래하는 것을 의미했습니다. 테스터에서도.
2. 우리는 모든 XXX 시스템에서 가상으로 거래하고, 지표를 평가하고, 실시간 인출을 위해 몇 가지를 선택하고, 이미 실제 거래를 엽니다.
가상 환경을 귀찮게 하고 싶지 않다면(기성품 fxsaber가 있지만) 통계를 위해 0.01랏을, 결과를 위해 1.00랏을 거래할 수 있습니다.
앉아서 데모를 볼 필요가 없습니다. 모든 것이 즉시 명확해질 것입니다.
1. 여기 이 차량의 경우 - 가능합니다. 항상 "최상의 시스템을 자동으로 선택하고 교환"하는 것은 아닙니다. 차량 매개변수의 평균값이 몇 가지 있는데, 선택하는 것이 프로그래밍하기 쉽지 않은 경우 각 "중간" 매개변수 값과 선택한 모든 "중간" 매개변수 값에 대해 결과를 확인해야 합니다. 이러한 캠페인을 통해 더 이상 "최고의 시스템을 자동으로 선택하고 이를 거래하는 것"이 아니라 더 신뢰할 수 있다고 생각합니다.
2. 절대적으로 사실입니다. 완전히 동의 해. 나 자신도 이 접근 방식을 귀찮게 할 것입니다. TC는 아직 이 테스트를 할 준비가 되지 않았습니다...
2016년부터... :-) 특별히 복잡한 것은 없지만 모든 것을 쓰지는 않았습니다. 어리석게도 시간이 없습니다. 일용할 양식에 대한 관심과 TS의 다른 개발은 이 방향으로 무한한 창의성에 참여하는 것을 허용하지 않습니다.
아 안드레이.... 내 아픈곳을 왜 밟아...
최고의 시스템을 선택하는 것은 마지막으로 해결되지 않은 문제입니다. "순전히 최고"를 취하는 것은 불가능합니다. 당신은 최고의 결과를 보여주었던 시스템을 가져갔고, 그것은 꽝 - 그리고 작동을 멈췄습니다. 테스트를 한 것 같고 이미 데모에서 12개 이상의 성공적인 거래를 보여주긴 했지만... 하지만, 밝혀진 바에 따르면 안정성이 없습니다... 그래서 차트를 보고 선택하고, 비교하고, 추정합니다. 원칙 자체의 성능... 그리고 결과적으로 실제 시스템을 설정하는 것은 공식보다 훨씬 더 직관적입니다. 그것을 인코딩하는 방법?
그리고 가상 환경은 어떻습니까? 모든 시스템을 데모에 넣을 수 있고 당신이 올바르게 제안한 대로 "통계를 위해 0.01 랏을 거래"할 수 있다면 강력한 컴퓨터와 함께 강력한 컴퓨터를 사용하는 것이 무슨 의미가 있습니까? 그래요. 나는 다락방에 2개의 터미널이 있는 오래된 컴퓨터를 가지고 있으며, 그것은 TS 리그의 중하위 부서를 운영합니다. 맨 위 디비전 - UPU에 있습니다 (우리는 종종 조명을 끄므로 맨 위 디비전의 경우 사용해야 함).
사실 내 TS 리그는 자동 모드에서 시스템을 지속적으로 테스트하는 "가상 환경"이기도 합니다. 여기 - 모든 것이 이미 해결되었으며 제어 매개 변수의 경우 재설치 절차도 이미 표준적이고 일상적입니다.
문제는 가장 안정적인 것을 선택하는 것입니다. 저는 "품질" 매개변수가 정말 마음에 들었습니다. 우리는 그것을 공식화했습니다. 그러나 매개 변수 "안정성"은 나에게 적합하지 않습니다. 이것은 기본적으로 내가 지금 작업하고 있는 것입니다.
:-) 테스트 및 매개 변수 선택 후 값의 의미에서 즉시 실제와 전투에 참여합니다. 당신은 그것을 실제의 데모에서 넣었습니다. 너무 늦게, 실제에서 제거하고 매개변수 값을 다시 최적화할 시간입니다...
실제 작업 시간은 물론 테스트의 20%-30%이며 트랜잭션 및 테스트 시간에 대한 명확한 테스트 샘플이 있습니다.
IMHO, 이 접근 방식은 올바르지 않습니다. " 이 날짜 이전에 2년 간의 테스트가 수행되고, 1년은 뒤로, 1년은 앞으로입니다. 이 날짜 이후 - TS가 데모에 설치되고 최고의 데모 시스템의 결과를 게시합니다." p.62에서.
이것은 내 질문에 대한 답변이 아닙니다.
테스터에서 작동하려면 시스템 선택 알고리즘이 필요합니다 . 그리고 그것을 확인하십시오. 데모는 전혀 필요하지 않으며 시간 낭비입니다.
이것은 아름답고 깊이 파고 들었습니다 ... :-)
나는 아직 지점의 해당 페이지에 도달하지 못했습니다 ... 나 자신이 거래에 대한 접근 방식이 다르기 때문에 ...
필요합니다. 하지만 돌꽃은 나오지 않고...
더 나아가 그것은 이미 분명하며 리그는 테스터에서 직접 최고의 차량을 선택할 수 있습니다(또는 스크립트와 테스터의 도움으로). 그러나 처음에는 선택 알고리즘을 테스터에 망치기 전에 발명해야 합니다! 즉, 적어도 "잡을" 것입니다. 어떻게 든 테스터에서 볼 수 있도록 가장 좋은 것을 강조 표시합니다. 이 알고리즘을 사용하여 시스템을 선택하면 더 나아가 안정적으로 작동합니까? 그리고 이것은 아닙니다!
여기에서 나는 공유 프로젝트를 위한 리그를 준비할 것입니다. 다시 바로 이 선택 알고리즘에서 실험을 할 것입니다.
그리고 "데모가 필요하지 않습니다"에 대해 - 동의하지 않습니다. 시스템의 안정성을 보려면 데모가 필요합니다 . 시스템이 테스터에서 작동하고 계속 작동하는지 확인하십시오.
나는 당신이 무덤에서 뼈를 일으킨 것을 계산하지 말라고 요청합니다. Robert Pardo의 링크에서 보십시오. 그는 최적화 및 기타 모든 것에 대한 모든 것을 능숙하게 그립니다.
https://www.mql5.com/ru/forum/131853/page4#comment_3359617
필요한 것은 데모가 아니라 최적화 프로세스 후 제안된 세트에서 매개변수의 평균값을 선택하기 위한 알고리즘 또는 접근 방식(원하는 대로 호출)입니다.
:-) 테스트 및 매개 변수 선택 후 값의 의미에서 - 즉시 실제와 전투에 참여합니다. 당신은 그것들을 실제에서, 늦게, 너무 늦게 실제에서 그것들을 제거하고 매개변수 값을 다시 최적화할 시간입니다...
실제 작업 시간은 물론 테스트의 20%-30%이며 트랜잭션 및 테스트 시간에 대한 명확한 테스트 샘플이 있습니다.
IMHO, 이 접근 방식은 올바르지 않습니다. " 이 날짜 이전에 2년 간의 테스트가 수행되고, 1년은 뒤로, 1년은 앞으로입니다. 이 날짜 이후 - TS가 데모에 설치되고 최고의 데모 시스템의 결과를 게시합니다." p.62에서.
데모 계정은 더 이상 "차량 추가 확인"을 위해 필요하지 않습니다(이것도 역할을 하지만). 데모 계정의 주요 임무는 좋은 거래 내역을 보여주는 시스템의 지속적인 존재 인 "TC 풀"입니다.
"실제 테스트의 20 %의 작업 시간"에 관해서는-이것은 양날의 검입니다. 즉, 2 년의 테스트 후 차량의 작동 시간이 최대 5 개월임을 의미하기 때문입니다. 또한 2년 테스트를 위한 6개월 데모 테스트, 우리는 이미 차량의 작동 시간이 최대 7개월입니다. 이는 눈에 띄게 더 길었습니다.
실제로 데모 계정의 존재는 - 아무 것도 변경하지 않습니다. 글쎄, 나는 데모 계정이 없을 것이고, 나는 실제에 즉시 베팅할 것입니다 - 그러나 질문은 동일하게 유지됩니다. 수백 대의 Top Division 차량 중 어느 것을 넣어야 할까요? ?
나는 당신이 무덤에서 뼈를 일으킨 것을 계산하지 말라고 요청합니다. Robert Pardo의 링크에서 보십시오. 그는 최적화 및 기타 모든 것에 대한 모든 것을 능숙하게 그립니다.
https://www.mql5.com/ru/forum/131853/page4#comment_3359617
필요한 것은 데모가 아니라 최적화 프로세스 후에 제안된 세트에서 매개변수의 평균값을 선택하기 위한 알고리즘 또는 접근 방식(원하는 대로 호출)입니다.
누가 주장 - 알고리즘 또는 접근 방식이 필요합니다. 여기에서 해결하려고 합니다(Pardo의 권장 사항 기반 포함). 그리고 이것이 바로 데모의 목적이기 때문에 매번 여러 시스템을 다시 최적화할 필요가 없고 얼마 동안 작동해 온 시스템을 즉시 사용합니다.
1. "차량 추가 확인"을 위해 데모 계정이 더 이상 필요하지 않습니다(이것도 역할을 하지만). 데모 계정의 주요 임무 는 좋은 거래 내역을 보여주는 시스템의 지속적인 존재인 "TC 풀"입니다.
2. "실제 근로시간은 시험의 20%다" - 양날의 검이라 2년의 시험 후 차량 운행시간이 최대 5개월이라는 의미이기 때문에, 2년 테스트를 위한 6개월 데모 테스트가 있는 경우 이미 최대 7개월의 차량 작동 시간이 있습니다. 이는 눈에 띄게 더 긴 것입니다.
3. 정말, 데모 계정의 존재 - 아무 것도 변경되지 않습니다. 음, 저는 데모 계정이 없을 것입니다. 즉시 실제에 베팅할 것입니다. 놓다?
1. 이해할 수 있다. 내가 이해하는 한, 당신은 거기에 모든 비용을 청구했고 최종 자금은 빨간색으로 표시되어 있습니다.
2. 그렇지 않습니다. 최적화 시간은 2년입니다. 차량의 작동 시간은 최대 5개월입니다. 또한, 이것은 데모용 반기 테스트가 아니며 이미 입찰하고 모든 테스트가 끝났습니다.
"그리고 데모를 위한 6개월 테스트가 있습니다. 그러면 우리는 이미 차량의 작동 시간이 최대 7개월입니다. 이는 눈에 띄게 더 길어집니다." - 아니요, 시장 업데이트를 위한 매개변수를 다시 최적화해야 합니다. 일반적으로 ATP 값과 같이 적응력을 갖는 것이 바람직합니다 ...
R. Pardo는 혼자 전문가가 아니지만 다른 출처와 MKL4 포럼에 대한 더 많은 토론을 기반으로 이 접근 방식이 고려되고 있습니다.
유전 알고리즘에 따라 매개변수가 최적화된 경우 최상의 모델 매개변수 값을 결정해야 합니다.
여기에서 매개 변수 값의 완전한 열거가 있기 때문에 어리석게도 최선을 취했습니다.
예를 들어 최적화 - 4년입니다. 앞으로 테스트 0.5년. 4의 0.5g은 12.5%입니다. 또한 반년의 시간 이동으로.
또한, 최상의 "모델"에 대한 매개변수를 선택하기 위한 특정 알고리즘을 사용하여 여러 최적화에 대한 전방 분석의 끝, 예를 들어 귀하와 같은 다음(극단적인) 최적화 후 2년 동안은 이미 없습니다. 분기당 포워드 테스트, 그러나 이미 거래 중이거나 실제 또는 데모에서 거래할 계정에 대한 귀하와 같은 시스템에 약간의 차이가 있는 경우.
3. 여기 예 ... 여기에서 결정해야합니다 ... :-) (생각이 있습니다-조금 후에 IMHO를 쓸 것입니다 ...)