최적화 시간 - 2년, 1년 전, 1년 전. 보고서는 매주 게시되며, 이는 시간의 약 0.2 - 1%임을 의미합니다(TS가 주의 시작 또는 끝에서 시작되는지 여부에 따라 다름).
동시에 TS는 10번의 거래 후에만 보고서에 포함될 수 있다는 점을 고려해야 합니다(그렇지 않으면 거래의 품질을 평가할 수 없음). 즉, TS가 자주 거래하는 경우 시스템이 시작된 후 보고서가 게시되기 전에 10건의 거래가 모두 완료되는 것이 가장 좋습니다. 즉, 이번 주 동안입니다. 하지만 한 달에 한두 번만 거래를 하는 차량이 있습니다. 그리고 물론 최적화 기간의 25%인 작업 6개월 후에만 보고서에 나타납니다.
또 다른 옵션이 있습니다. 이것은 시스템이 처음에 하위 또는 중간 디비전에 속하는 경우(역사 결과에 따라) 그리고 갑자기 상위 디비전에 합당한 거래 품질을 보여주기 시작하는 경우입니다(역 후행 시스템의 경우- "sixes" 또는 "sevens" - 이것은 매우 쉽게 발생합니다). 이 경우 높은 거래 품질을 감지한 직후(당일) 최상위 부문으로 이동하여 거래 품질을 측정하기 위해 다시 10번의 거래를 해야 하며, 등급에 있습니다. 그러나 시스템이 처음 10번의 트랜잭션을 수행한 후 최상위 디비전에 진입한 후 다시 중간 또는 하위 디비전의 품질을 보여주고 다시 원래 위치로 돌아오는 경우가 있습니다.
1. 최적화 시간 - 2년, 1년 전, 1년 전 . 보고서는 매주 게시되며, 이는 시간의 약 0.2 - 1%임을 의미합니다(TS가 주의 시작 또는 끝에서 시작되는지 여부에 따라 다름).
동시에 TS는 10번의 거래 후에만 보고서에 포함될 수 있다는 점을 고려해야 합니다(그렇지 않으면 거래의 품질을 평가할 수 없음). 즉, TS가 자주 거래하는 경우 시스템이 시작된 후 보고서가 게시되기 전에 10건의 거래가 모두 완료되는 것이 가장 좋습니다. 즉, 이번 주 동안입니다. 하지만 한 달에 한두 번만 거래를 하는 차량이 있습니다. 그리고 물론 최적화 기간의 25%인 작업 6개월 후에만 보고서에 나타납니다.
2. 또 다른 옵션이 있습니다. 이것은 시스템이 처음에 하위 또는 중간 디비전으로 떨어지는 경우(역사 결과에 따라), 갑자기 상위 디비전에 합당한 거래 품질을 보여주기 시작합니다. 이 경우 높은 거래 품질을 감지한 직후(당일) Top Division으로 이동하고 그곳에서 다시 10번의 거래를 수행하여 거래 품질을 측정해야 합니다. 등급. 그러나 시스템이 처음 10번의 트랜잭션을 수행한 후 최상위 디비전에 진입한 후 다시 중간 또는 하위 디비전의 품질을 보여주고 다시 원래 위치로 돌아오는 경우가 있습니다.
1. 여기. 이것들은 매우 중요한 것들입니다. 아마도 선도 기간이 최적화 기간의 20%보다 높지 않은 방식으로 거래를 고려하는 것이 합리적일 것입니다. 이 값을 초과하면 시간 프레임에 따라 제어 샷을 기다리지 않고 차량을 다시 최적화해야 합니다.
2. 그게 요점입니다. 예를 들어 이 10건의 거래는 "우호적인 시간대" 이후에 이루어집니다. 그것이 쏟아지는 이유입니다... 왜냐하면. 포워드는 실제 거래 또는 데모 거래와 동일시될 수 있지만 중요하지 않습니다.
요컨대, 지금과 같은 접근 방식에서는 forward가 최적화 시간의 50%일 때 새로운 최적화를 위해 TS를 보내야 합니다.
아마도 최소한 이 접근 방식(최적화, 시간의 25%)을 앞으로, (뒤로 - 흥미롭지 않음), 그런 다음 데모를 볼 수 있으므로 최적화의 최대 50%(25% 이후)까지 시간이 있습니다. 앞으로) - 현재 매개변수에 대한 거래 비용 ... 최대 50% 최적화 시간.
요컨대, 지금과 같은 접근 방식에서는 forward가 최적화 시간의 50%일 때 새로운 최적화를 위해 TS를 보내야 합니다.
아마도 적어도 이 접근 방식(최적화, 시간의 25%)을 앞으로, (뒤로 - 흥미롭지 않음), 데모를 볼 수 있으므로 최적화의 최대 50%까지 시간이 있습니다(25% 이후 앞으로) - 현재 매개변수에 대한 거래 비용 ... 최대 50% 최적화 시간.
무엇보다 SUSTAINABLE 매개변수를 찾아야 하는 것 같습니다. 그리고 이차적으로만 높습니다.
그리고 차량이 먼저 한 부문에 속하고 다른 부문의 품질을 보이기 시작하면 이것은 불안정성의 신호입니다. 예를 들어 Igor Chechet은 시스템이 거래의 품질을 향상시켰더라도 그러한 행동은 "컨트롤 샷"과 동일시해야 하며 즉시 거래에서 시스템을 제거해야 한다고 말합니다.
그렇기 때문에 대부분의 경우 구매를 판매로 "전환"할 때 수익성이 없는 시스템이 수익성 있는 시스템으로 바뀌지 않으며 그 반대의 경우도 마찬가지입니다. 수익성이 없는 시스템의 주요 문제는 불안정성입니다. 그리고 구매가 판매로 바뀌면 불안정성이 남습니다. 따라서 시스템 병합을 계속합니다.
그리고 차량이 먼저 한 부문에 속하고 다른 부문의 품질을 보이기 시작하면 이것은 불안정성의 신호입니다. 예를 들어 Igor Chechet은 시스템이 거래의 품질을 향상시켰더라도 그러한 행동은 "컨트롤 샷"과 동일시해야 하며 즉시 거래에서 시스템을 제거해야 한다고 말합니다.
그렇기 때문에 대부분의 경우 구매를 판매로 "전환"할 때 수익성이 없는 시스템이 수익성 있는 시스템으로 바뀌지 않으며 그 반대의 경우도 마찬가지입니다. 수익성이 없는 시스템의 주요 문제는 불안정성입니다. 그리고 구매가 판매로 바뀌면 불안정성이 남습니다. 따라서 시스템 병합을 계속합니다.
예, 높음 / 낮음 매개 변수에 관한 것이 아닙니다. ANY, 글쎄, 아무 것도 아니지만 그 이상 - 안정성 - 최소한 테스트의 50% 후에 통과하고 최소한 최적화 시간이 지나기 때문에 시장은 변화하고 있으며 최적화를 수행하는 매개변수의 실제 값을 다시 선택해야 합니다.
나는 최적화에 대한 유능한 접근 방식이라고 생각합니다. Robert Pardo "주식 거래자를 위한 거래 시스템의 개발, 테스트 및 최적화"
예, 높음 / 낮음 매개 변수에 관한 것이 아닙니다. ANY, 글쎄, 아무 것도 아니지만 그 이상 - 안정성 - 최소한 테스트의 50% 후에 통과하고 최소한 최적화 시간이 지나기 때문에 시장은 변화하고 있으며 최적화를 수행하는 매개변수의 실제 값을 다시 선택해야 합니다.
나는 최적화에 대한 유능한 접근 방식이라고 생각합니다. Robert Pardo "주식 거래자를 위한 거래 시스템의 개발, 테스트 및 최적화"
포워드를 25% 최적화로 줄여서 최대 50% 최적화까지 실제 매개변수를 거래할 시간이 있습니다.
저것들. 선택하는 경우 2년(3년을 선택하는 것이 더 낫지만), 다음 분기 - 포워드(25%)(가능한 경우 더 적은 것이 더 낫지만 거래 수에 따른 샘플의 유효성에 따라 다름), 포워드가 좋으면 다음 분기가 좋아 - 분기 (25 %) 이상 - 데모 / 실제 ... 최소한 그런 것 ...
일반적으로, 최적화 후 (STABLE) 매개변수의 값을 선택하는 순서와 어떤 정방향도 없이 스스로 결정하십시오. 최적화 시간의 30% 동안 즉시 데모/실제입니다.
포워드를 25% 최적화로 줄여서 최대 50% 최적화까지 실제 매개변수를 거래할 시간이 있습니다.
저것들. 선택하는 경우 2년(3년을 선택하는 것이 더 낫지만), 다음 분기 - 포워드(25%)(가능한 경우 더 적은 것이 더 낫지만 거래 수에 따른 샘플의 유효성에 따라 다름), 포워드가 좋으면 다음 분기가 좋아 - 분기 (25 %) 이상 - 데모 / 실제 ... 최소한 그런 것 ...
일반적으로 최적화 후 매개변수 값을 선택하는 순서는 정방향으로 진행하지 않고 바로 데모/실제 최적화 시간의 30% 동안 스스로 결정합니다.
여기 다시... 로만, 당신의 구체적인 제안이 무엇인지 이해가 되지 않습니다. 뒤로 기간을 변경하시겠습니까? 그렇다면 어떤 것이 있습니까?
1년~1년은 꽤 합리적인 기간이라고 생각합니다. 그러나 나는 또한 당신의 주장에 동의하는 경향이 있습니다. 나는 당신이 제안한 기간을 알지 못합니다. 3-0.25? 2-0? 아니면 얼마?
명확히 하고 싶었습니다. 최적화 시간 간격의 몇 퍼센트 후에 보고서를 게시합니까?
자, 추측해 봅시다.
최적화 시간 - 2년, 1년 전, 1년 전. 보고서는 매주 게시되며, 이는 시간의 약 0.2 - 1%임을 의미합니다(TS가 주의 시작 또는 끝에서 시작되는지 여부에 따라 다름).
동시에 TS는 10번의 거래 후에만 보고서에 포함될 수 있다는 점을 고려해야 합니다(그렇지 않으면 거래의 품질을 평가할 수 없음). 즉, TS가 자주 거래하는 경우 시스템이 시작된 후 보고서가 게시되기 전에 10건의 거래가 모두 완료되는 것이 가장 좋습니다. 즉, 이번 주 동안입니다. 하지만 한 달에 한두 번만 거래를 하는 차량이 있습니다. 그리고 물론 최적화 기간의 25%인 작업 6개월 후에만 보고서에 나타납니다.
또 다른 옵션이 있습니다. 이것은 시스템이 처음에 하위 또는 중간 디비전에 속하는 경우(역사 결과에 따라) 그리고 갑자기 상위 디비전에 합당한 거래 품질을 보여주기 시작하는 경우입니다(역 후행 시스템의 경우- "sixes" 또는 "sevens" - 이것은 매우 쉽게 발생합니다). 이 경우 높은 거래 품질을 감지한 직후(당일) 최상위 부문으로 이동하여 거래 품질을 측정하기 위해 다시 10번의 거래를 해야 하며, 등급에 있습니다. 그러나 시스템이 처음 10번의 트랜잭션을 수행한 후 최상위 디비전에 진입한 후 다시 중간 또는 하위 디비전의 품질을 보여주고 다시 원래 위치로 돌아오는 경우가 있습니다.자, 추측해 봅시다.
1. 최적화 시간 - 2년, 1년 전, 1년 전 . 보고서는 매주 게시되며, 이는 시간의 약 0.2 - 1%임을 의미합니다(TS가 주의 시작 또는 끝에서 시작되는지 여부에 따라 다름).
동시에 TS는 10번의 거래 후에만 보고서에 포함될 수 있다는 점을 고려해야 합니다(그렇지 않으면 거래의 품질을 평가할 수 없음). 즉, TS가 자주 거래하는 경우 시스템이 시작된 후 보고서가 게시되기 전에 10건의 거래가 모두 완료되는 것이 가장 좋습니다. 즉, 이번 주 동안입니다. 하지만 한 달에 한두 번만 거래를 하는 차량이 있습니다. 그리고 물론 최적화 기간의 25%인 작업 6개월 후에만 보고서에 나타납니다.
2. 또 다른 옵션이 있습니다. 이것은 시스템이 처음에 하위 또는 중간 디비전으로 떨어지는 경우(역사 결과에 따라), 갑자기 상위 디비전에 합당한 거래 품질을 보여주기 시작합니다. 이 경우 높은 거래 품질을 감지한 직후(당일) Top Division으로 이동하고 그곳에서 다시 10번의 거래를 수행하여 거래 품질을 측정해야 합니다. 등급. 그러나 시스템이 처음 10번의 트랜잭션을 수행한 후 최상위 디비전에 진입한 후 다시 중간 또는 하위 디비전의 품질을 보여주고 다시 원래 위치로 돌아오는 경우가 있습니다.1. 여기. 이것들은 매우 중요한 것들입니다. 아마도 선도 기간이 최적화 기간의 20%보다 높지 않은 방식으로 거래를 고려하는 것이 합리적일 것입니다. 이 값을 초과하면 시간 프레임에 따라 제어 샷을 기다리지 않고 차량을 다시 최적화해야 합니다.
2. 그게 요점입니다. 예를 들어 이 10건의 거래는 "우호적인 시간대" 이후에 이루어집니다. 그것이 쏟아지는 이유입니다... 왜냐하면. 포워드는 실제 거래 또는 데모 거래와 동일시될 수 있지만 중요하지 않습니다.
요컨대, 지금과 같은 접근 방식에서는 forward가 최적화 시간의 50%일 때 새로운 최적화를 위해 TS를 보내야 합니다.
아마도 최소한 이 접근 방식(최적화, 시간의 25%)을 앞으로, (뒤로 - 흥미롭지 않음), 그런 다음 데모를 볼 수 있으므로 최적화의 최대 50%(25% 이후)까지 시간이 있습니다. 앞으로) - 현재 매개변수에 대한 거래 비용 ... 최대 50% 최적화 시간.
요컨대, 지금과 같은 접근 방식에서는 forward가 최적화 시간의 50%일 때 새로운 최적화를 위해 TS를 보내야 합니다.
아마도 적어도 이 접근 방식(최적화, 시간의 25%)을 앞으로, (뒤로 - 흥미롭지 않음), 데모를 볼 수 있으므로 최적화의 최대 50%까지 시간이 있습니다(25% 이후 앞으로) - 현재 매개변수에 대한 거래 비용 ... 최대 50% 최적화 시간.
무엇보다 SUSTAINABLE 매개변수를 찾아야 하는 것 같습니다. 그리고 이차적으로만 높습니다.
그리고 차량이 먼저 한 부문에 속하고 다른 부문의 품질을 보이기 시작하면 이것은 불안정성의 신호입니다. 예를 들어 Igor Chechet은 시스템이 거래의 품질을 향상시켰더라도 그러한 행동은 "컨트롤 샷"과 동일시해야 하며 즉시 거래에서 시스템을 제거해야 한다고 말합니다.
그렇기 때문에 대부분의 경우 구매를 판매로 "전환"할 때 수익성이 없는 시스템이 수익성 있는 시스템으로 바뀌지 않으며 그 반대의 경우도 마찬가지입니다. 수익성이 없는 시스템의 주요 문제는 불안정성입니다. 그리고 구매가 판매로 바뀌면 불안정성이 남습니다. 따라서 시스템 병합을 계속합니다.
먼저 STABLE 매개변수를 찾아야 하는 것 같습니다. 그리고 이차적으로만 높습니다.
그리고 차량이 먼저 한 부문에 속하고 다른 부문의 품질을 보이기 시작하면 이것은 불안정성의 신호입니다. 예를 들어 Igor Chechet은 시스템이 거래의 품질을 향상시켰더라도 그러한 행동은 "컨트롤 샷"과 동일시해야 하며 즉시 거래에서 시스템을 제거해야 한다고 말합니다.
그렇기 때문에 대부분의 경우 구매를 판매로 "전환"할 때 수익성이 없는 시스템이 수익성 있는 시스템으로 바뀌지 않으며 그 반대의 경우도 마찬가지입니다. 수익성이 없는 시스템의 주요 문제는 불안정성입니다. 그리고 구매가 판매로 바뀌면 불안정성이 남습니다. 따라서 시스템 병합을 계속합니다.
예, 높음 / 낮음 매개 변수에 관한 것이 아닙니다. ANY, 글쎄, 아무 것도 아니지만 그 이상 - 안정성 - 최소한 테스트의 50% 후에 통과하고 최소한 최적화 시간이 지나기 때문에 시장은 변화하고 있으며 최적화를 수행하는 매개변수의 실제 값을 다시 선택해야 합니다.
나는 최적화에 대한 유능한 접근 방식이라고 생각합니다. Robert Pardo "주식 거래자를 위한 거래 시스템의 개발, 테스트 및 최적화"예, 높음 / 낮음 매개 변수에 관한 것이 아닙니다. ANY, 글쎄, 아무 것도 아니지만 그 이상 - 안정성 - 최소한 테스트의 50% 후에 통과하고 최소한 최적화 시간이 지나기 때문에 시장은 변화하고 있으며 최적화를 수행하는 매개변수의 실제 값을 다시 선택해야 합니다.
나는 최적화에 대한 유능한 접근 방식이라고 생각합니다. Robert Pardo "주식 거래자를 위한 거래 시스템의 개발, 테스트 및 최적화"나는 당신의 구체적인 제안을 잘 이해하지 못합니다.
테스트 기간을 앞뒤로 변경하시겠습니까? 무엇을 위해? (이제 1년은 1년)
티
나는 당신의 구체적인 제안을 잘 이해하지 못합니다.
테스트 기간을 앞뒤로 변경하시겠습니까? 무엇을 위해? (이제 1년은 1년)
포워드를 25% 최적화로 줄여서 최대 50% 최적화까지 실제 매개변수를 거래할 시간이 있습니다.
저것들. 선택하는 경우 2년(3년을 선택하는 것이 더 낫지만), 다음 분기 - 포워드(25%)(가능한 경우 더 적은 것이 더 낫지만 거래 수에 따른 샘플의 유효성에 따라 다름), 포워드가 좋으면 다음 분기가 좋아 - 분기 (25 %) 이상 - 데모 / 실제 ... 최소한 그런 것 ...
일반적으로, 최적화 후 (STABLE) 매개변수의 값을 선택하는 순서와 어떤 정방향도 없이 스스로 결정하십시오. 최적화 시간의 30% 동안 즉시 데모/실제입니다.
포워드를 25% 최적화로 줄여서 최대 50% 최적화까지 실제 매개변수를 거래할 시간이 있습니다.
저것들. 선택하는 경우 2년(3년을 선택하는 것이 더 낫지만), 다음 분기 - 포워드(25%)(가능한 경우 더 적은 것이 더 낫지만 거래 수에 따른 샘플의 유효성에 따라 다름), 포워드가 좋으면 다음 분기가 좋아 - 분기 (25 %) 이상 - 데모 / 실제 ... 최소한 그런 것 ...
일반적으로 최적화 후 매개변수 값을 선택하는 순서는 정방향으로 진행하지 않고 바로 데모/실제 최적화 시간의 30% 동안 스스로 결정합니다.
여기 다시... 로만, 당신의 구체적인 제안이 무엇인지 이해가 되지 않습니다. 뒤로 기간을 변경하시겠습니까? 그렇다면 어떤 것이 있습니까?
1년~1년은 꽤 합리적인 기간이라고 생각합니다. 그러나 나는 또한 당신의 주장에 동의하는 경향이 있습니다. 나는 당신이 제안한 기간을 알지 못합니다. 3-0.25? 2-0? 아니면 얼마?
여기 다시... 로만, 당신의 구체적인 제안이 무엇인지 이해가 되지 않습니다. 뒤로 기간을 변경하시겠습니까? 그렇다면 어떤 것이 있습니까?
1년~1년은 꽤 합리적인 기간이라고 생각합니다. 그러나 나는 또한 당신의 주장에 동의하는 경향이 있습니다. 나는 당신이 제안한 기간을 알지 못합니다.
최적화 기간 2, 더 나은 3년, 그 다음 분기 1, 그 다음 분기 1부터 거래.
결과적으로 2년 동안 100% 최적화를 수행하고 1/4(최적화 시간의 12.5%)을 앞당기면 좋은 경우 컨트롤 샷 이전에 이미 거래되고 있는 것입니다.
물론 더 나은 것은 3년의 최적화 - 그 다음 4분의 1(최적화의 8% - 앞으로), 앞으로 - 좋은 - 다음 입찰입니다.
최적화 시간의 25% 이전에 거래를 시작하려면 . 이 같은.
전나무, 여기 당신이 사랑합니다, 로만, 모호함 ... "둘이지만 셋이 더 좋습니다"... 그래서 어떤 종류의 제안? 두세개?
그러나 3은 30보다 훨씬 더 합리적으로 보이지 않습니다. 유로가 연일 하락하던 완화 기간에 시스템을 최적화하는 것이 무슨 소용입니까? 지금은 없어진지 오래...