이상적인 기계 거래 시스템. - 페이지 4

 
sashken писал (а):
eugenk1 은 다음과 같이 썼습니다.
지금까지는 모든 것이 훨씬 쉬워 보입니다. 최소한의 설정으로 간단하고 순진한 시스템으로 시작해야 합니다. 그리고 실시간으로 매개변수의 적응형 변경 블록을 추가합니다...

이제 조금 남았습니다. 적응 매개변수를 계산하는 데 사용할 데이터를 결정해야 합니다. 무엇을 제안해야 할지조차 모르겠습니다. :(
누구든지 이것에 대한 아이디어가 있습니까?

다음 차량 모델을 제안하는 것으로 시작할 수 있습니다.
우리는 간단한 Expert Advisor를 사용하여 "테스터" 블록을 작성합니다(이 작업에는 하루에 한 번, 예를 들어 GMT 01:00에 TS를 월별 기록으로 조정).
 
xeon을 사용하면 테스터가 최소한 지속적으로 작동하도록 만들 수 있습니다. 물론 mql4가 아닌 고도로 최적화된 C로 작성해야 합니다. 아아, 이 모든 것에는 한 가지 매우 심각한 함정이 있습니다. 즉, 시스템의 평가 및 최적화 기간입니다. 저것들. 성능을 평가하는 데 얼마나 걸립니까? 실제 거래에 대한 권리를 놓고 경쟁하는 두 가지 전략이 있다고 가정해 보겠습니다. 성공적인 현재 및 최악의 백업. 예를 들어 한 시간 만에 현재 전략이 유출된 반면 백업 전략은 성공했습니다. 문제는 전략을 바꾸느냐, 바꾸지 않느냐이다. 결국 이것은 새로운 트렌드의 시작(트렌드/플랫과 혼동하지 말 것!)이거나 우연일 수 있습니다. 저것들. 그러한 테스터 자체에는 평가 및 최적화 기간과 같은 조정 가능한 매개 변수가 하나 이상 있습니다. 그러한 접근의 불가능성에 대해 내가 말하는 것을 이해하지 못합니다. 나는 이 모든 것이 어려움과 안개가 자욱한 곳이 있다는 것을 말하고 있습니다.
 
eugenk1 писал (а):
xeon을 사용하면 테스터가 최소한 지속적으로 작동하도록 만들 수 있습니다. 물론 mql4가 아닌 고도로 최적화된 C로 작성해야 합니다. 아아, 이 모든 것에는 한 가지 매우 심각한 함정이 있습니다. 즉, 시스템의 평가 및 최적화 기간입니다. 저것들. 성능을 평가하는 데 얼마나 걸립니까? 실제 거래에 대한 권리를 놓고 경쟁하는 두 가지 전략이 있다고 가정해 보겠습니다. 성공적인 현재 및 최악의 백업. 예를 들어 한 시간 만에 현재 전략이 유출된 반면 백업 전략은 성공했습니다. 문제는 전략을 바꾸느냐, 바꾸지 않느냐이다. 결국 이것은 새로운 트렌드의 시작(트렌드/플랫과 혼동하지 말 것!)이거나 우연일 수 있습니다. 저것들. 그러한 테스터 자체에는 평가 및 최적화 기간과 같은 조정 가능한 매개 변수가 하나 이상 있습니다. 그러한 접근의 불가능성에 대해 내가 말하는 것을 이해하지 못합니다. 나는 이 모든 것이 어려움과 안개가 자욱한 곳이 있다는 것을 말하고 있습니다.

어쨌든 간단한 것을 시도해 봅시다.
문제: 월간 기록을 하루에 한 번 실행하고 손절매 매개변수에 대한 최적의 수를 설정하는 함수를 작성할 수 있습니까?
그리고 가장 중요한 것: 이 기능으로 테스터를 확인할 수 있습니까? 테스터가 전혀 작동합니까? 매일 테스트 모드에서 그는 새로운 날에 대해 중지 매개변수를 변경해야 하는 것으로 나타났습니다. 가능합니까? 이 문제를 해결하면 나머지는 이미 말했듯이 착빙입니다.
 
후행 정지가 MACD에 따라 달라지면 적응 세척이라고 할 수 있습니까?
 
quality писал (а):
eugenk1 은 다음과 같이 썼습니다.
xeon을 사용하면 테스터가 최소한 지속적으로 작동하도록 만들 수 있습니다. 물론 mql4가 아닌 고도로 최적화된 C로 작성해야 합니다. 아아, 이 모든 것에는 한 가지 매우 심각한 함정이 있습니다. 즉, 시스템의 평가 및 최적화 기간입니다. 저것들. 성능을 평가하는 데 얼마나 걸립니까? 실제 거래에 대한 권리를 놓고 경쟁하는 두 가지 전략이 있다고 가정해 보겠습니다. 성공적인 현재 및 최악의 백업. 예를 들어 한 시간 만에 현재 전략이 유출된 반면 백업 전략은 성공했습니다. 문제는 전략을 바꾸느냐, 바꾸지 않느냐이다. 결국 이것은 새로운 트렌드의 시작(트렌드/플랫과 혼동하지 말 것!)이거나 우연일 수 있습니다. 저것들. 그러한 테스터 자체에는 평가 및 최적화 기간과 같은 조정 가능한 매개 변수가 하나 이상 있습니다. 그러한 접근의 불가능성에 대해 내가 말하는 것을 이해하지 못합니다. 나는 이 모든 것이 어려움과 안개가 자욱한 곳이 있다는 것을 말하고 있습니다.

어쨌든 간단한 것을 시도해 봅시다.
문제: 월간 기록을 하루에 한 번 실행하고 손절매 매개변수에 대한 최적의 수를 설정하는 함수를 작성할 수 있습니까?
그리고 가장 중요한 것: 이 기능으로 테스터를 확인할 수 있습니까? 테스터가 전혀 작동합니까? 매일 테스트 모드에서 그는 새로운 날에 대해 중지 매개변수를 변경해야 하는 것으로 나타났습니다. 가능합니까? 이 문제를 해결하면 나머지는 이미 말했듯이 착빙입니다.

내가 아는 한 이러한 테스터 기능을 mql로 작성할 수는 있지만 이 작업은 내가 "아마추어 프로그래머"이고 시간이 필요하기 때문에 쉽지 않습니다.
 

자체 조정 지표는 막다른 골목입니다. 나는 내 의견을 입증하려고 노력할 것이다.
나는 그러한 지표를 여러 개 개발했지만 다른 DC에서 오는 시세의 변동성에 민감한 것으로 판명되었습니다. 즉, 이러한 표시기는 한 DC의 데이터에서 완벽하게 작동하고 다른 DC의 데이터에서는 전혀 작동하지 않습니다. 국회 데이터에 대한 모든 작업 중 최악. DC에서 시세의 평균 움직임은 동일하지만 변동성이 다르기 때문에 지표가 혼동됩니다. 예를 들어, 동일한 견적 간격의 표준 지표에서도 한 DC에는 차이가 있지만 다른 DC에는 차이가 없습니다.
내 연구에 따르면 변동성은 자체 조정 지표에서 고려해야 하는 주요 요인입니다. 그러나 결과적으로 표시기는 다른 DC에서 인용을 필터링하는 방법과 이 방법의 변경(DC에서 알리지 않음)에 따라 달라집니다.
여기서 나는 자체 조정이 불연속(선형)이 아니라 일정하기 때문에 "거칠게(roughen up)"(Renat이 계속 이야기하고 있음)하는 것이 불가능하다는 사실에 직면했습니다.

변동성 문제에서 벗어날 수있는 유일한 방법 은 지표와 시세의 절대 가치 를 고려하지 않는 것입니다. 저것들. MTS에서 결정을 내리기 위해서는 어떤 형태로든 값의 비율을 사용해야 하며 이것이 본질적으로 패턴 인식입니다.



 
아르템RG
그것!
 
ArtemRG :

자체 조정 지표는 막다른 골목입니다. 나는 내 의견을 입증하려고 노력할 것이다.
나는 그러한 지표를 여러 개 개발했지만 다른 DC에서 오는 시세의 변동성에 민감한 것으로 판명되었습니다. 즉, 이러한 표시기는 한 DC의 데이터에서 완벽하게 작동하고 다른 DC의 데이터에서는 전혀 작동하지 않습니다. 국회 데이터에 대한 모든 작업 중 최악. DC에서 시세의 평균 움직임은 동일하지만 변동성이 다르기 때문에 지표가 혼동됩니다. 예를 들어, 동일한 견적 간격의 표준 지표에서도 한 DC에는 차이가 있지만 다른 DC에는 차이가 없습니다.
내 연구에 따르면 변동성은 자체 조정 지표에서 고려해야 하는 주요 요인입니다. 그러나 결과적으로 표시기는 다른 DC에서 인용을 필터링하는 방법과 이 방법의 변경(DC에서 알리지 않음)에 따라 달라집니다.
여기서 나는 자체 조정이 불연속(선형)이 아니라 일정하기 때문에 "거칠게(roughen up)"(Renat이 계속 이야기하고 있음)하는 것이 불가능하다는 사실에 직면했습니다.

변동성 문제에서 벗어날 수있는 유일한 방법은 지표와 시세의 절대 가치를 고려하지 않는 것입니다. 저것들. MTS에서 결정을 내리기 위해서는 어떤 형태로든 값의 비율을 사용해야 하며 이것이 본질적으로 패턴 인식입니다.



나는 "자체 조정 지표는 막다른 골목"이라는 진술에 다소 동의하지 않을 수 있습니다. 나머지는 동의하지만. 나는 단지 같은 문제에 대해 많은 해결책이 있을 수 있다고 생각합니다. 예를 들어, 질문에: - "거칠게 하다"(Renat가 항상 이야기하는) 자기 조정. - 표시기 값을 거칠게 하는 것이 아니라 "노이즈" 수준을 줄일 수 있는 필터를 사용하는 약간 다른 솔루션을 찾았습니다.
 
힌트를 좀 드릴까요? :)

모든 시스템에서 중요한 것은 가격 값이 아니라 변경 속도(때로는 단지 표시일 뿐입니다)입니다.
때때로 가격 가속이 사용됩니다(선행 지표로서 가격에 작용하는 힘의 추정치).
MTS와 함께 사용되는 모든 표시기는 실제로 속도를 평가하도록 설계되었습니다.
다른 지표는 속도를 평가하기 위한 다른 옵션일 뿐입니다.

1. 모든 오실레이터는 속도, 때로는 가속도(예: MACD)를 평가합니다.

2. 모든 이동 평균 은 단독으로 사용되지 않습니다.
다른 이동 평균과 비교할 때만(가격은 길이가 1인 이동 평균임).
이동 평균의 이러한 비교(실제로 그 차이를 0과 비교)는 오실레이터입니다.

3. 가격이 아닌 가격의 대수를 고려할 필요가 있다.
로그에서는 모든 것이 더 단순해지고 정확해집니다.
작은 가격 변화로 가격과 로그로 작업하는 데 차이가 없을 것입니다.
큰 가격 변동으로 그 차이는 상당할 것입니다.
 
Mak писал (а):
힌트를 좀 드릴까요? :)

모든 시스템에서 중요한 것은 가격 값이 아니라 변경 속도(때로는 단지 표시일 뿐입니다)입니다.
때때로 가격 가속이 사용됩니다(선행 지표로서 가격에 작용하는 힘의 추정치).
MTS와 함께 사용되는 모든 표시기는 실제로 속도를 평가하도록 설계되었습니다.
다른 지표는 속도를 평가하기 위한 다른 옵션일 뿐입니다.

1. 모든 오실레이터는 속도, 때로는 가속도(예: MACD)를 평가합니다.

2. 모든 이동 평균 은 단독으로 사용되지 않습니다.
다른 이동 평균과 비교할 때만(가격은 길이가 1인 이동 평균임).
이동 평균의 이러한 비교(실제로 그 차이를 0과 비교)는 오실레이터입니다.

3. 가격이 아닌 가격의 대수를 고려할 필요가 있다.
로그에서는 모든 것이 더 단순해지고 정확해집니다.
작은 가격 변화로 가격과 로그로 작업하는 데 차이가 없을 것입니다.
큰 가격 변동으로 그 차이는 상당할 것입니다.

코드 작성에 참여할 수도 있습니까? :-), 프로그래밍 경험이 있다면 훨씬 더 빠르게 진행될 것입니다!