포워드의 수익성에 따른 지표 선택은 99%의 경우 조정입니다. 이 경우에만 훈련 시리즈의 매개변수뿐만 아니라 순방향 시리즈의 매개변수에 따라 피팅이 수행됩니다. 적합하지만 더 긴 행에 적합
용어를 이해합시다.
과거 데이터(논리, 지표, 이러한 지표에 대한 변수 등)에 대해 무엇이든 선택할 때 - 이것은 일반적으로 "적합"이라고 부를 수 있으며 "좋은" 의미와 "나쁜" 의미 모두에서 이 단어 . 그러나 코드 매개변수 또는 해당 속성의 SELECTION 프로세스가 있다고 말하는 것이 좋습니다. 하나와 다른 하나의 최상의 조합을 반복적으로 선택합니다. 일반적으로 "적합"은 여전히 역사의 동일한 섹션에 대한 여러 테스트를 통해 얻은 가장 인상적인 변수 값의 반 악의적 인 선택이라고하며 인접 항목이 아닌 이 동일한 섹션에 대해 표시됩니다. 전방에서는 다중 선택이 발생하지 않습니다.
포워드는 최적화되지 않은 히스토리에 대한 일회성 확인입니다. 앞으로 우리에게 남은 것은 슬프거나 그 결과에 기뻐하거나 어떤 결론을 내리는 것뿐이지만, 이는 원칙에 위배되기 때문에 더 이상 영향을 줄 수 없습니다. 포워드에 영향을 미치려면 원래 세그먼트로 돌아가서 무언가를 다시 해야 합니다. 근본적인 차이점은 포워드를 추가하여 "더 긴 행"을 얻는 것이 아니라 코드가 처음으로 포워드 기록의 한 부분에 도달한다는 것입니다. 최적화된 영역의 "확장"이 발생하지 않습니다. 따라서 여기에서 "아름다움을 위한 선택"이라는 의미의 "피팅"이라는 용어는 원칙적으로 사용할 수 없습니다. 그러나 포워드가 선택을 위해 봉사합니까? 물론, 하지만 다른 무엇? 그러나 이 선택은 원칙적으로 일시적인 코드 변수를 선택하기 위한 것이 아닙니다. 그 목적은 코드 자체 - 논리와 품질입니다.
"향후 수익성에 기반한 지표 선택 - 99%의 경우 조정"과 같은 문구는 어떤 시점에서 사람들이 단순히 개념을 대체하여 결점을 더 깊고 힘들게 이해하지 않으려는 자신의 의지를 무의식적으로 정당화하는 자기기만의 생생한 예입니다. 코드의. 즉, 더 아름다운 포워드를 달성하기 위해 설정이 아닌 지표를 변경할 때 이것은 정상적인 선택이지만 포워드에 대한 일회성 검증의 원칙이 준수되는 경우에만 가능합니다. 그러한 과정을 적합하다고 하기는 어렵습니다.
과거 데이터(논리, 지표, 이러한 지표에 대한 변수 등)에 대해 무엇이든 선택할 때 - 이것은 일반적으로 "적합"이라고 부를 수 있으며 "좋은" 의미와 "나쁜" 의미 모두에서 이 단어 . 그러나 코드 매개 변수 또는 해당 속성의 SELECTION 프로세스가 있다고 말하는 것이 좋습니다. 하나와 다른 하나의 최상의 조합을 반복적으로 선택합니다. 일반적으로 "적합"은 여전히 역사의 동일한 섹션에 대한 여러 테스트를 통해 얻은 가장 인상적인 변수 값의 반 악의적 인 선택이라고하며 인접 항목이 아닌 이 동일한 섹션에 대해 표시됩니다. 전방에서는 다중 선택이 발생하지 않습니다.
포워드는 최적화되지 않은 히스토리에 대한 일회성 확인입니다. 앞으로 우리에게 남은 것은 슬프거나 그 결과에 기뻐하거나 어떤 결론을 내리는 것뿐이지만, 이는 원칙에 위배되기 때문에 더 이상 영향을 줄 수 없습니다. 포워드에 영향을 미치려면 원래 세그먼트로 돌아가서 무언가를 다시 해야 합니다. 근본적인 차이점은 포워드를 추가하여 "더 긴 행"을 얻는 것이 아니라 코드가 처음으로 포워드 기록의 한 부분에 도달한다는 것입니다. 최적화된 영역의 "확장"이 없습니다. 따라서 여기에서는 "아름다움을 위한 선택"이라는 의미의 "피팅"이라는 용어를 원칙적으로 사용할 수 없습니다. 그러나 포워드가 선택을 위해 봉사합니까? 물론, 하지만 다른 무엇? 그러나 이 선택은 원칙적으로 일시적인 코드 변수를 선택하기 위한 것이 아닙니다. 그 목적은 코드 자체 - 논리와 품질입니다.
"향후 수익성에 기반한 지표 선택 - 99%의 경우 조정"과 같은 문구는 어떤 시점에서 사람들이 단순히 개념을 대체하여 결점을 더 깊고 힘들게 이해하지 않으려는 자신의 의지를 무의식적으로 정당화하는 자기기만의 생생한 예입니다. 코드의. 즉, 지표를 변경할 때 더 아름다운 포워드를 달성하려고 할 때 이것은 정상적인 선택이지만 포워드에 대한 단일 확인의 원칙이 준수되는 경우에만 가능합니다. 그러한 과정을 적합하다고 하기는 어렵습니다.
많고 아무것도 없습니다.
지표를 가지고 100가지 방법으로 설정을 변경하고 그 중 20가지가 백 테스트에서 긍정적인 MO를 제공합니다.
20개를 앞으로 실행 - 그 중 5개는 앞으로 긍정적인 MO를 제공합니다. 전방에 최대 MO를 제공하는 5 가지 표시기 설정 중에서 선택합니다.
지표를 가지고 100가지 방법으로 설정을 변경하고 그 중 20가지가 백 테스트에서 긍정적인 MO를 제공합니다.
20개를 앞으로 실행 - 그 중 5개는 앞으로 긍정적인 MO를 제공합니다. 전방에 최대 MO를 제공하는 5 가지 표시기 설정 중에서 선택합니다.
따라서 이것은 뒤쪽뿐만 아니라 앞쪽에도 모두 동일합니다.
그리고 다시 한 번 용어에 대해 역사의 결과에서 선택 은 더 이상 앞으로가 아니라 최적화입니다. 이러한 옵션이 전방에서 선택되었다는 사실은 변경되거나 개선되지 않습니다(현재에서 이야기가 끝날 때 어떻게 5개의 전방을 얻을 수 있습니까?). 저것들. 당신은 먼저 정방향 확인의 원칙을 위반한 다음 적합하고 나빴다고 말했습니다. 확실히 적합하지만 표시기 설정의 더 작은 선택에서 적합합니다. 우선 원칙에 어긋나지 않고 의논할 수 있습니다. 포워드의 역학이 없으면 안정성이 반복성이고 포워드가 하나만 있기 때문에 지표 자체의 속성이 안정적인지 아닌지에 대해 아무 말도 할 수 없습니다. 또한 설정에 대한 옵션이 아닌 INDICATORS의 선택에 대해 먼저 이야기했습니다. 실제 정방향 확인은 설정이 아니라 코드의 안정성을 알아내기 위해 설계되었습니다. 즉, 여러 전달의 결과를 비교하여 한 곳에서 시간을 표시하여 얻은 설정 묶음이 아닙니다. 저것들. 다른 포워드(특정 사이트에 대한 유일한 것)를 비교하는 것은 최적화되지 않은 많은 사이트를 비교한 결과이며 자체와 비교한 결과가 아닙니다.
Youri Tarshecki : 그리고 다시 한 번 용어에 대해 역사의 결과에서 선택 은 더 이상 앞으로가 아니라 최적화입니다. 이러한 옵션이 전방에서 선택되었다는 사실은 변경되거나 개선되지 않습니다(현재에서 이야기가 끝날 때 어떻게 5개의 전방을 얻을 수 있습니까?). 저것들. 당신은 먼저 정방향 확인의 원칙을 위반한 다음 적합하고 나빴다고 말했습니다. 확실히 적합하지만 표시기 설정의 더 작은 선택에서 적합합니다. 우선 원칙에 어긋나지 않고 의논할 수 있습니다. 포워드의 역학이 없으면 지표 자체의 속성이 안정적인지 아닌지에 대해 말할 수 없습니다. 또한 설정에 대한 옵션이 아닌 INDICATORS의 선택에 대해 먼저 이야기했습니다. 실제 정방향 확인은 설정이 아니라 코드의 안정성을 알아내기 위해 설계되었습니다. 즉, 여러 전달의 결과를 비교하여 한 곳에서 시간을 표시하여 얻은 설정 묶음이 아닙니다. 저것들. 다른 포워드(특정 사이트에 대한 유일한 것)를 비교하는 것은 최적화되지 않은 많은 사이트를 비교한 결과이지 자체와 비교한 결과가 아닙니다.
정방향 확인이 수행되는 방법 - 기본부터 시작합니다.
샘플을 특정 비율(예: 80/20)로 앞뒤로 나누어 채취합니다.
그리고 어떻게 정방향 확인이 수행될 것이라고 생각했습니까? 전체 샘플이 현재 순간까지 선택되어 백으로 받아들여집니다. 그리고 그 결과는 견적이 들어오면 전달자에 의해 실시간으로 테스트됩니까? 그리고 앞으로 얼마나 걸릴까요????
포워드의 수익성에 기반한 지표 선택은 99%의 경우에 적합합니다. 이 경우에만 훈련 시리즈의 매개변수뿐만 아니라 순방향 시리즈의 매개변수에 따라 피팅이 수행됩니다. 적합하지만 더 긴 행에 적합
동의한다. 다만 나는 그것을 의미하지 않았다. 수익성 있는 포워드는 코드가 좋고 나쁨을 의미하지 않습니다. 수익성 있는 포워드는 시장이 관성과 같은 속성을 가지고 있음을 의미합니다. 백 테스트에서 식별된 패턴에 따라 움직였습니다.
동의한다. 다만 나는 그것을 의미하지 않았다. 수익성 있는 포워드는 코드가 좋고 나쁨을 의미하지 않습니다. 수익성 있는 포워드는 시장이 관성과 같은 속성을 가지고 있음을 의미합니다. 백 테스트에서 식별된 패턴에 따라 움직였습니다.
이러한 결론은 앞뒤의 결과가 최소한 거의 같을 때만 도출할 수 있습니다.
아니 어떻게 이렇게 촘촘할 수 있지)
당신은 테스트 결과 의 분석과 검증에 대한 포럼이 아니라 스마트 북을 읽습니다. 스레드의 대부분의 질문은 즉시 사라집니다.
아니 어떻게 이렇게 촘촘할 수 있지)
당신은 테스트 결과 의 분석과 검증에 대한 포럼이 아니라 스마트 북을 읽습니다. 스레드의 대부분의 질문은 즉시 사라집니다.
포워드의 수익성에 따른 지표 선택은 99%의 경우 조정입니다. 이 경우에만 훈련 시리즈의 매개변수뿐만 아니라 순방향 시리즈의 매개변수에 따라 피팅이 수행됩니다. 적합하지만 더 긴 행에 적합
용어를 이해합시다.
과거 데이터(논리, 지표, 이러한 지표에 대한 변수 등)에 대해 무엇이든 선택할 때 - 이것은 일반적으로 "적합"이라고 부를 수 있으며 "좋은" 의미와 "나쁜" 의미 모두에서 이 단어 . 그러나 코드 매개변수 또는 해당 속성의 SELECTION 프로세스가 있다고 말하는 것이 좋습니다. 하나와 다른 하나의 최상의 조합을 반복적으로 선택합니다. 일반적으로 "적합"은 여전히 역사의 동일한 섹션에 대한 여러 테스트를 통해 얻은 가장 인상적인 변수 값의 반 악의적 인 선택이라고하며 인접 항목이 아닌 이 동일한 섹션에 대해 표시됩니다. 전방에서는 다중 선택이 발생하지 않습니다.
포워드는 최적화되지 않은 히스토리에 대한 일회성 확인입니다. 앞으로 우리에게 남은 것은 슬프거나 그 결과에 기뻐하거나 어떤 결론을 내리는 것뿐이지만, 이는 원칙에 위배되기 때문에 더 이상 영향을 줄 수 없습니다. 포워드에 영향을 미치려면 원래 세그먼트로 돌아가서 무언가를 다시 해야 합니다. 근본적인 차이점은 포워드를 추가하여 "더 긴 행"을 얻는 것이 아니라 코드가 처음으로 포워드 기록의 한 부분에 도달한다는 것입니다. 최적화된 영역의 "확장"이 발생하지 않습니다. 따라서 여기에서 "아름다움을 위한 선택"이라는 의미의 "피팅"이라는 용어는 원칙적으로 사용할 수 없습니다. 그러나 포워드가 선택을 위해 봉사합니까? 물론, 하지만 다른 무엇? 그러나 이 선택은 원칙적으로 일시적인 코드 변수를 선택하기 위한 것이 아닙니다. 그 목적은 코드 자체 - 논리와 품질입니다.
"향후 수익성에 기반한 지표 선택 - 99%의 경우 조정"과 같은 문구는 어떤 시점에서 사람들이 단순히 개념을 대체하여 결점을 더 깊고 힘들게 이해하지 않으려는 자신의 의지를 무의식적으로 정당화하는 자기기만의 생생한 예입니다. 코드의. 즉, 더 아름다운 포워드를 달성하기 위해 설정이 아닌 지표를 변경할 때 이것은 정상적인 선택이지만 포워드에 대한 일회성 검증의 원칙이 준수되는 경우에만 가능합니다. 그러한 과정을 적합하다고 하기는 어렵습니다.
용어를 이해합시다.
과거 데이터(논리, 지표, 이러한 지표에 대한 변수 등)에 대해 무엇이든 선택할 때 - 이것은 일반적으로 "적합"이라고 부를 수 있으며 "좋은" 의미와 "나쁜" 의미 모두에서 이 단어 . 그러나 코드 매개 변수 또는 해당 속성의 SELECTION 프로세스가 있다고 말하는 것이 좋습니다. 하나와 다른 하나의 최상의 조합을 반복적으로 선택합니다. 일반적으로 "적합"은 여전히 역사의 동일한 섹션에 대한 여러 테스트를 통해 얻은 가장 인상적인 변수 값의 반 악의적 인 선택이라고하며 인접 항목이 아닌 이 동일한 섹션에 대해 표시됩니다. 전방에서는 다중 선택이 발생하지 않습니다.
포워드는 최적화되지 않은 히스토리에 대한 일회성 확인입니다. 앞으로 우리에게 남은 것은 슬프거나 그 결과에 기뻐하거나 어떤 결론을 내리는 것뿐이지만, 이는 원칙에 위배되기 때문에 더 이상 영향을 줄 수 없습니다. 포워드에 영향을 미치려면 원래 세그먼트로 돌아가서 무언가를 다시 해야 합니다. 근본적인 차이점은 포워드를 추가하여 "더 긴 행"을 얻는 것이 아니라 코드가 처음으로 포워드 기록의 한 부분에 도달한다는 것입니다. 최적화된 영역의 "확장"이 없습니다. 따라서 여기에서는 "아름다움을 위한 선택"이라는 의미의 "피팅"이라는 용어를 원칙적으로 사용할 수 없습니다. 그러나 포워드가 선택을 위해 봉사합니까? 물론, 하지만 다른 무엇? 그러나 이 선택은 원칙적으로 일시적인 코드 변수를 선택하기 위한 것이 아닙니다. 그 목적은 코드 자체 - 논리와 품질입니다.
"향후 수익성에 기반한 지표 선택 - 99%의 경우 조정"과 같은 문구는 어떤 시점에서 사람들이 단순히 개념을 대체하여 결점을 더 깊고 힘들게 이해하지 않으려는 자신의 의지를 무의식적으로 정당화하는 자기기만의 생생한 예입니다. 코드의. 즉, 지표를 변경할 때 더 아름다운 포워드를 달성하려고 할 때 이것은 정상적인 선택이지만 포워드에 대한 단일 확인의 원칙이 준수되는 경우에만 가능합니다. 그러한 과정을 적합하다고 하기는 어렵습니다.
많고 아무것도 없습니다.
지표를 가지고 100가지 방법으로 설정을 변경하고 그 중 20가지가 백 테스트에서 긍정적인 MO를 제공합니다.
20개를 앞으로 실행 - 그 중 5개는 앞으로 긍정적인 MO를 제공합니다. 전방에 최대 MO를 제공하는 5 가지 표시기 설정 중에서 선택합니다.
따라서 이것은 뒤쪽뿐만 아니라 앞쪽에도 모두 동일합니다.
동의한다. 다만 나는 그것을 의미하지 않았다. 수익성 있는 포워드는 코드가 좋고 나쁨을 의미하지 않습니다. 수익성 있는 포워드는 시장이 관성과 같은 속성을 가지고 있음을 의미합니다. 백 테스트에서 식별된 패턴에 따라 움직였습니다.
많고 아무것도 없습니다.
지표를 가지고 100가지 방법으로 설정을 변경하고 그 중 20가지가 백 테스트에서 긍정적인 MO를 제공합니다.
20개를 앞으로 실행 - 그 중 5개는 앞으로 긍정적인 MO를 제공합니다. 전방에 최대 MO를 제공하는 5 가지 표시기 설정 중에서 선택합니다.
따라서 이것은 뒤쪽뿐만 아니라 앞쪽에도 모두 동일합니다.
그리고 다시 한 번 용어에 대해 역사의 결과에서 선택 은 더 이상 앞으로가 아니라 최적화입니다. 이러한 옵션이 전방에서 선택되었다는 사실은 변경되거나 개선되지 않습니다(현재에서 이야기가 끝날 때 어떻게 5개의 전방을 얻을 수 있습니까?). 저것들. 당신은 먼저 정방향 확인의 원칙을 위반한 다음 적합하고 나빴다고 말했습니다. 확실히 적합하지만 표시기 설정의 더 작은 선택에서 적합합니다. 우선 원칙에 어긋나지 않고 의논할 수 있습니다. 포워드의 역학이 없으면 지표 자체의 속성이 안정적인지 아닌지에 대해 말할 수 없습니다. 또한 설정에 대한 옵션이 아닌 INDICATORS의 선택에 대해 먼저 이야기했습니다. 실제 정방향 확인은 설정이 아니라 코드의 안정성을 알아내기 위해 설계되었습니다. 즉, 여러 전달의 결과를 비교하여 한 곳에서 시간을 표시하여 얻은 설정 묶음이 아닙니다. 저것들. 다른 포워드(특정 사이트에 대한 유일한 것)를 비교하는 것은 최적화되지 않은 많은 사이트를 비교한 결과이지 자체와 비교한 결과가 아닙니다.
정방향 확인이 수행되는 방법 - 기본부터 시작합니다.
샘플을 특정 비율(예: 80/20)로 앞뒤로 나누어 채취합니다.
그리고 어떻게 정방향 확인이 수행될 것이라고 생각했습니까? 전체 샘플이 현재 순간까지 선택되어 백으로 받아들여집니다. 그리고 그 결과는 견적이 들어오면 전달자에 의해 실시간으로 테스트됩니까? 그리고 앞으로 얼마나 걸릴까요????