tol64 : 어떤 현실을 말하는 겁니까? 실시간 테스트? 그렇다면 확실히 동의합니다. 두 명의 전문가를 기호에 매달면 모든 것이 정확할 것입니다. 하지만 다중 통화 모드를 테스트 중입니다. 그리고 OnTimer () 함수(10초)에서만 동일한 결과가 나타납니다.
다중 통화 모드(각 기호에 대해 설정된 Expert Advisors(각 Expert Advisor에서)의 N 기호에 대한 거래)에서의 실제 출시에 대해 이야기하고 있습니다. 이는 실제 평가를 제공하며 테스터의 경우 먼저 다중 통화 틱 처리 방법에서 각각의 올바른 작동이 아닌 테스트 모드 를 비교하십시오. 서로 다른 모드가 모두 테스터의 인공 환경을 기반으로 하는 경우 비교하는 의미가 무엇입니까? 실행 결과의 동일성은 거래 측면에서 가장 정확한 결과를 제공한다고 주장하는 근거를 제공하지 않으며 이것은 테스터의 내부 메커니즘 관점에서 최적입니다.
올바른 표현부터 시작하겠습니다. 원래 예에서는 "유로달러가 거래됨"을 원합니다. 실제로 사용자 이벤트 는 두 개의 기호에서 수신되었으며 이벤트 처리기에서는 이 두 기호 중 하나에서 이벤트가 수신될 때 TradeSignalCounter()+TradePerformer() 함수가 호출되었습니다. 이벤트 큐가 항상 한계까지 채워졌다고 가정할 수 있습니다.
이제 신호 소스 중 하나를 제거했지만 어떤 이유로 이벤트 핸들러에서 " if (sparam == Symbol_01)" 검사를 입력했습니다. 그러나 또 다른 질문은 다릅니다. 코드로 판단하면 "All ticks" 모드에서 Lizar의 방식을 사용하고 신호 소스(EURUSD)의 각 틱마다 TradeSignalCounter()+TradePerformer() 함수가 호출됩니다. 관심은 이미 이벤트 대기열의 오버플로 가능성에 대해 암시했습니다. 이 두 함수의 Symbol_01 매개변수로 어떤 도구를 사용하는지 궁금하며, Lizar의 방식에서 이벤트 빈도를 변경해 보셨습니까?
예, 싶었어요. 결국 우리의 모든 행동은 욕망에 의해 유발됩니다. 이 경우 내가 원하는 것을 정확히 얻었습니다. 즉, 심볼 배열의 각 심볼에 대한 TradePerformer () 함수에서 거래 허가를 확인하기 때문에 EURUSD 에서만 거래가 이루어졌습니다. 이 옵션은 외부 변수에 있으며 당시 GBPUSD 기호에 대한 거래가 금지되었습니다. 사용자 이벤트는 두 개의 기호에서 발생했지만 이벤트 핸들러에서 TradePerformer () 함수는 EURUSD 기호에서만 거래를 허용했습니다. TradePerformer () 함수에는 특정 기호(이 경우 EURUSD )에서 새로운 막대가 발생했는지 여부를 결정하는 함수도 포함되어 있습니다. 이벤트 대기열이 항상 가득 찼다는 가정은 정확했지만 이 경우 모든 것이 별도로 처리되었으며 일일 막대에서 테스트할 때 1틱 지연이 중요하지 않습니다.
테스트에 참여하지 말아야 할 하나의 신호 소스를 제거하면 모든 것이 이전에 올바르게 수행되었음을 확인할 수 있었습니다. " if (sparam == Symbol_01)" 테스트는 테스트해서는 안되지만 통과해야 하는 신호 소스를 제거하지 않고 결과를 확인할 때 남은 것입니다. 이 검사는 실제로 불필요한 것으로 판명되었습니다. 결과는 변경되지 않았습니다. Symbol_01 매개변수는 EURUSD 기호입니다. 이벤트 빈도를 변경하려고 시도했지만 아무 것도 변경되지 않았습니다. 더 정확히 말하면 올티키 모드가 가장 정확하다고 할 수 있다.
다중 통화 모드(각 기호에 대해 설정된 Expert Advisors(각 Expert Advisor에서)의 N 기호에 대한 거래)에서의 실제 출시에 대해 이야기하고 있습니다. 이는 실제 평가를 제공하며 테스터의 경우 먼저 테스트 모드 를 비교하고 각 다중 통화 틱 처리 방법의 올바른 작동이 아닙니다. 서로 다른 모드가 모두 테스터의 인공 환경을 기반으로 하는 경우 비교하는 의미가 무엇입니까? 실행 결과의 동일성은 거래 측면에서 가장 정확한 결과를 제공한다고 주장하는 근거를 제공하지 않으며 이것은 테스터의 내부 메커니즘 관점에서 최적입니다.
이제 명확해졌습니다. 그러나 처음에는 테스터에서 테스트하는 것에 대한 논의가 있었습니다. 결국, 거래를 시작하기 전에 시스템을 테스트해야 합니다. 그리고 테스트가 더 정확하게 수행될수록 실제 거래에서 더 큰 자신감을 느낄 것입니다. 제시된 테스트 결과는 정확하고 부정확하게 테스트할 수 있는 것을 보여줍니다. 이제 모든 사람이 선택권을 가지며 무엇이 옳고 그른지를 스스로 결정할 수 있습니다. 거래자 중 한 명이 매우 올바르게 말했습니다(내가 틀리지 않았다면 이것은 Van Tharp입니다): "우리는 우리의 아이디어로 거래합니다." 이 문장에 덧붙일 수 있습니다. 우리는 단순히 아이디어를 판매하지 않습니다. 우리는 심지어 우리의 생각으로만 살고 있습니다. ))
실제 거래나 테스트에서 각 기호에 전문가를 별도로 배치하면 이것이 가장 정확한 옵션이 될 것입니다. 나는 물론 이것에 동의합니다. 그러나 이를 위해 막대를 동기화할 필요가 없습니다. 정확성에는 지속 시간이 따릅니다. 테스터에서 긴 과거 기간을 평가할 수 있습니다. 그리고 개인적으로는 정확한 검사 결과를 보고 싶습니다.
한 가지만 더 말씀드리자면, 제가 어딘가에 실수할 가능성을 절대 배제하지 않고 항상 모든 것을 확인하고 있습니다. 그러나 가장 엄격한 검사를 거친 후에도 언뜻보기에는 모든 것이 괜찮아 보이지만 어딘가에 오류가있을 수 있음을 배제하지 않습니다. 현재 누군가가 제시된 테스트 방법의 결과 평가에 동의하지 않으면 테스트 결과를 비교하여 제공해야 합니다. 결국 이 스레드의 목적은 올바르게 수행하는 방법, 또는 더 정확하게는 다중 통화 Expert Advisors를 올바르게 테스트하는 방법을 찾는 것입니다. 말로만 옳고 그름은 아닙니다. 팩트, 팩트만 팩트, 팩트만! )))
서로 다른 모드가 모두 테스터의 인공 환경을 기반으로 하는 경우 비교하는 의미가 무엇입니까?
요점은 얻은 결과에 따라 올바른 결정을 내리는 것입니다. 하지만 왜곡된 데이터를 분석하는 데에는 아무런 의미가 없습니다. 결국 뿌린 대로 거둡니다.
테스트에 참여하지 말아야 할 하나의 신호 소스를 제거하면 모든 것이 이전에 올바르게 수행되었음을 확인할 수 있었습니다.
"... 그 전에 모든 것이 올바르게 완료되었습니다." - 이것은 안일함의 범주에 속합니다. 처음에는 틀렸습니다. 분명히 당신은 "이벤트 대기열의 오버플로"와 같은 현상을 중요하게 생각하지 않습니다. 특히 틱으로 이벤트를 전송할 때. 이 주제에 대한 도움말 자료와 포럼을 살펴보십시오. 키워드는 "대기열"입니다.
톨64 :
... 기호 배열의 각 기호에 대한 TradePerformer () 함수에 거래 허가 확인이 있기 때문에 거래는 EURUSD 에서만 수행되었습니다. 이 옵션은 외부 변수에 있으며 당시 GBPUSD 기호에 대한 거래가 금지되었습니다. 사용자 이벤트 는 두 개의 기호에서 발생했지만 이벤트 핸들러에서 TradePerformer () 함수는 EURUSD 기호에서만 거래를 허용했습니다. TradePerformer () 함수에는 특정 기호(이 경우 EURUSD )에서 새로운 막대가 발생했는지 여부를 결정하는 함수도 포함되어 있습니다. 이벤트 대기열이 항상 가득 찼다는 가정은 정확했지만 이 경우 모든 것이 별도로 처리되었으며 일일 막대에서 테스트할 때 1틱 지연이 중요하지 않습니다.
TradeSignalCounter()+TradePerformer() 함수가 하나의 신호 소스에서만 이벤트를 처리했다는 사실은 이벤트 큐의 상태와 가능한 오버플로를 변경하지 않았습니다. 즉, "GBRUSD 기호에 대한 이벤트 처리 금지"는 이벤트 대기열에서 해당 이벤트를 전혀 제거하지 않았습니다. 세 번째로 저는 문제에 주의를 기울였습니다. "관심은 이미 이벤트 대기열의 오버플로 가능성에 대해 암시했습니다." :) 우리가 "한 틱 지연"에 대해 이야기하고 있다고 생각한다면 그러한 결론은 무엇을 기반으로 합니까?
"...이 경우 모든 것이 별도로 처리되었습니다." 문제는 원래 버전에서 이벤트 핸들러가 두 신호 소스에서 이벤트를 수신할 때 함수를 호출한 다음 이러한 함수가 "불필요한" 소스에서 신호를 필터링했다는 것입니다. 그러나 함수는 (!) 시간마다 호출되었습니다.
톨64 :
일일 막대에서 테스트할 때 1틱 지연은 중요하지 않습니다.
예, 이벤트 핸들러가 테스트되는 기간은 중요하지 않습니다. Lizar의 계획이 틱당 신호를 생성하면 하루에 한 번이 아니라 틱당 이벤트 대기열을 채웁니다.
"이벤트 빈도를 변경해 보았지만 달라지는 것은 없었습니다. 정확히는 올틱 모드가 가장 정확하다고 할 수 있습니다." Lizar의 비틱 모드에 대한 비교 스크린샷을 제공할 수 있습니까?
실제 거래나 테스트에서 각 기호에 전문가를 별도로 배치하면 이것이 가장 정확한 옵션이 될 것입니다. 나는 물론 이것에 동의합니다. 그러나 이를 위해 막대를 동기화할 필요가 없습니다. 정확성에는 지속 시간이 따릅니다. 테스터에서 긴 과거 기간을 평가할 수 있습니다. 그리고 개인적으로는 정확한 검사 결과를 보고 싶습니다.
막대를 온라인으로 동기화할 필요가 없는 이유는 무엇입니까?! 테스터의 이러한 모든 실험은 온라인 거래를 평가하기 위해 필요하며, 이 주제의 문제는 테스터(온라인을 에뮬레이트하는)가 아닌 온라인의 문제에 있으며, 무엇보다도 온라인에서 막대의 동기화가 필요합니다. 해당 전문가 고문).
톨64 :
요점은 얻은 결과에 따라 올바른 결정을 내리는 것입니다. 하지만 왜곡된 데이터를 분석하는 데에는 아무런 의미가 없습니다. 결국 뿌린 대로 거둡니다.
"정확성" 범주가 이제 테스터 실행 ID로 대체되었다는 점을 지적하려고 합니다. 그러나 그렇다고 해서 그러한 데이터가 덜 왜곡된 것은 아닙니다. 특히, 이제 10초 간격을 선택했는데 의심할 여지 없이 5초 또는 1초 간격보다 더 많이 데이터를 왜곡합니다. 저것들. 10초 타이머로 선호하는 방법을 제공하는 테스터 환경의 기능을 활용하고 있습니다. 사실, 타이머 이벤트가 있는 모든 악기에 새 막대의 틱이 도착 하는 순간을 "잡으려고" 하고 있으며 이를 수행하는 가장 좋은 방법은 OnTick 이벤트입니다.
Язык программирования MQL5 позволяет решать задачи на совершенно новом уровне. Даже те задачи, которые уже вроде имеют решения, благодаря объектно-ориентированному программированию могут подняться на качественно новый уровень. В данной статье специально взят простой пример проверки появления нового бара на графике, который был преобразован в достаточно мощный и универсальный инструмент. Какой? Читайте в статье.
MetaTrader 5 позволяет во встроенном тестере стратегий моделировать автоматическую торговлю с помощью экспертов на языке MQL5. Такое моделирование называется тестированием экспертов, и может проводиться с использованием многопоточной оптимизации и одновременно по множеству инструментов. Для проведения тщательного тестирования требуется генерировать тики на основе имеющейся минутной истории. В статье дается подробное описание алгоритма, по которому генерируются тики для исторического тестирования в клиентском терминале MetaTrader 5.
"... 그 전에 모든 것이 올바르게 완료되었습니다." - 이것은 안일함의 범주에 속합니다.
---
좋은 아침! ))
이 문구 외에도 텍스트와 별도로 찢어서 다음과 같이 썼습니다. "... 나는 어딘가에서 실수 한 것을 배제하지 않고 항상 모든 것을 확인합니다. 그러나 가장 엄격한 검사 후에도 모든 것이 언뜻보기에 올바르게 보일 때 , 나는 여전히 어딘가에 버그가 있을 수 있다는 것을 배제하지 않습니다 . 나는 모든 것에 대해 항상 옳다고 생각하는 사람들의 범주에 속하지 않는다고 덧붙일 것입니다. )))
---
예델킨: 처음에는 틀렸습니다. 분명히 당신은 "이벤트 대기열의 오버플로"와 같은 현상을 중요하게 생각하지 않습니다. 특히 틱으로 이벤트를 전송할 때. 이 주제에 대한 도움말 자료와 포럼을 살펴보십시오. 키워드는 "대기열"입니다.
즉, EURUSD 기호에서만 CHARTEVENT_TICK 이벤트를 수락합니다. 다른 캐릭터는 없습니다.
테스트가 시작되었습니다. 이벤트가 발생하면 프로그램은 OnChartEvent () 함수를 입력하고 거래 신호에 대한 변수 배열을 선언하고 이벤트가 무엇인지 확인합니다. 이것이 사용자 정의 이벤트인 경우 프로그램은 TradeSignalCounter()에서 신호를 정의한 다음 TradePerformer( ) 함수에서 새 막대가 도착했는지 여부를 확인하고 이에 따라 다른 조건을 결정합니다. 함수는 작업을 완료했으며 EURUSD 차트에서 이벤트가 발생한 후에만 시작됩니다. 이 경우 틱입니다.
voidOnChartEvent ( constint id, // идентификатор событияconstlong & lparam, // флаг события поступившего от агента панели.// Флаги соответствуют перечислению ENUM_CHART_EVENT_SYMBOL.constdouble & dparam, // ценаconststring & sparam // инструмент
)
{
// Объявление массивов переменных для торговых сигналовstaticdatetime New_Bar[ 1 ];
staticbool UpSignal[ 1 ], DnSignal[ 1 ];
if (id >= CHARTEVENT_CUSTOM )
{
// Получение торговых сигналов
TradeSignalCounter( 0 ,Symbol_01,Trade_01,Timeframe_01,UpSignal,DnSignal,New_Bar);
// Совершение торговых операций
TradePerformer( 0 ,Symbol_01,Trade_01,Timeframe_01,Stop_Loss_01,Take_Profit_01,Slippage_01,UpSignal,DnSignal,New_Bar);
}
}
예델킨: TradeSignalCounter() + TradePerformer( ) 함수가 하나의 신호 소스에서만 이벤트를 처리했다는 사실은 이벤트 큐의 상태와 가능한 오버플로를 변경하지 않았습니다. 즉, " GBRUSD 기호에 대한 이벤트 처리 금지"는 이벤트 대기열에서 해당 이벤트를 전혀 제거하지 않았습니다. 세 번째로 저는 문제에 주의를 기울였습니다. "관심은 이미 이벤트 대기열의 오버플로 가능성에 대해 암시했습니다." :) 우리가 "한 틱 지연"에 대해 이야기하고 있다고 생각한다면 그러한 결론은 무엇을 기반으로 합니까?
---
이러한 기능의 실행은 매우 빠릅니다. 이벤트 대기열은 오버플로할 시간이 없으며 중요한 이벤트를 놓치지 않습니다. 그리고 대기열이 오버플로되고 이벤트가 건너뛴다면 무엇을 놓치게 될까요? 똑딱, 둘, 셋? 글쎄요? 이것은 일일 바에서 무시할 수 있습니다.
---
예델킨: 문제는 원래 버전에서 이벤트 핸들러가 두 신호 소스에서 이벤트를 수신할 때 함수를 호출한 다음 이러한 함수가 "불필요한" 소스에서 신호를 필터링했다는 것입니다. 그러나 함수는 (!) 시간마다 호출되었습니다.
--- 왜이 두 번째 소스에 집착합니까.))) 더 이상 두 번째 소스가 없습니다. EURUSD 가 하나 있지만 EA는 GBPUSD 에서 EURUSD 차트로 거래합니다. 그리고 결과도 똑같이 틀립니다. 복사. 즉, 두 번째 소스가 있는 것과 동일합니다. )))
-----------
테스트를 직접 해보고, 테스트 결과를 보여주고, 당신이 할 수 있다면 정확한 테스트 결과를 얻기 위해 무엇을 했는지 (간단히) 쓰는 것이 좋습니다. 가장 간단한 Expert Advisor가 이 테스트에 적합합니다. 모든 조건에 의한 진입, 손절매, 이익실현. 지난 10년 동안 매일 바를 보자. 그리고 당신 자신이 직접 보게 될 것입니다. 일부는 일치하고 일부는 일치하지 않습니다. 결과 그래프를 열고 불일치가 있는 위치를 확인합니다.
다중 통화 모드(각 기호에 설정된 EA(각 EA)의 N 기호에 대한 거래)에서의 실제 실행에 대해 이야기하고 있습니다. 이는 실제 추정치를 제공합니다.
이를 통해 실제 출시란 여러 Expert Advisor가 출시되고 각각이 고유한 기호에 직접 매달릴 때 온라인 테스트를 의미한다는 것을 이해했습니다. 그것이 당신이 의미하는 바라면 질문은 다음과 같습니다. 이 경우 각 Expert Advisor가 고유한 기호에 매달리는 경우 막대를 동기화해야 하는 이유는 무엇입니까? 거래 시스템이 한 번에 여러 기호에 대해 결정이 내려지는 방식으로 설계된 경우 이 경우 막대의 동기화가 필요할 수 있으므로 이러한 여러 기호에 막대가 형성되어야 합니다. 하나의 심볼(모든 심볼에 대해)에 있는 동안 여러 심볼에 대한 독립적인 거래를 의미합니다.
마케터 :
테스터의 이러한 모든 실험은 온라인 거래를 평가하기 위해 필요하며, 이 주제의 문제는 테스터(온라인을 에뮬레이트하는)가 아닌 온라인의 문제에 있으며, 무엇보다도 온라인에서 막대의 동기화가 필요합니다. 해당 전문가 고문).
저에게 있어 히스토리 거래의 결과를 평가하기 위해서는 테스터에서의 실험이 필요합니다. 그리고 온라인 거래에 대한 나의 선택은 이 평가에 달려 있습니다. 따라서 이 주제의 문제는 온라인이 아닌 테스터의 문제에 있으며, 그렇기 때문에 테스터에서도 막대의 동기화가 필요합니다(관련 전문가의 경우). 일종의 거울 이미지.
마케터 :
"정확성" 범주가 이제 테스터 실행 ID로 대체되었음을 지적하려고 합니다. 그러나 그렇다고 해서 그러한 데이터가 덜 왜곡된 것은 아닙니다. 특히, 이제 10초 간격을 선택했는데 의심할 여지 없이 5초 또는 1초 간격보다 더 많이 데이터를 왜곡합니다. 저것들. 10초 타이머로 선호하는 방법을 제공하는 테스터 환경의 기능을 활용하고 있습니다.
예, 간격이 작을수록 결과가 더 정확합니다. 그러나 사실, 그것은 적어도 나에게는 마지막 시험에 필요합니다. 그리고 예비의 경우 1분 간격이면 충분하다는 Vladimir( MetaDriver )의 의견에 여전히 동의합니다.
마케터 :
사실, 타이머 이벤트가 있는 모든 악기에 새 막대의 틱이 도착 하는 순간을 "잡으려고" 하고 있으며 이를 수행하는 가장 좋은 방법은 OnTick 이벤트입니다.
그리고 여기에서 주제의 첫 번째 게시물을 부주의하게 읽었음을 알 수 있습니다. 타이머 이벤트가 아니라 OnChartEvent ()입니다. 아니면 오타인가요?
지금은 한동안 토론을 이어갈 수 없을 것 같아서, 조금 이따가 어느 날, 돋보기로 말해서 좀 더 철저하게 연구를 해봐야겠습니다. 아마도 이것은 내가 무엇을 잘못하고 있는지 또는 이것 또는 그 방법의 오류가 무엇인지 빠르게 이해하는 데 도움이 될 것입니다. 의견을 주신 모든 분들께 감사드립니다.
이를 통해 실제 출시란 여러 Expert Advisor가 출시되고 각각이 고유한 기호에 직접 매달릴 때 온라인 테스트를 의미한다는 것을 이해했습니다. 그것이 당신이 의미하는 바라면 질문은 다음과 같습니다. 이 경우 각 Expert Advisor가 고유한 기호에 매달리는 경우 막대를 동기화해야 하는 이유는 무엇입니까? 거래 시스템이 한 번에 여러 기호에 대해 결정이 내려지는 방식으로 설계된 경우 이 경우 막대의 동기화가 필요할 수 있으므로 이러한 여러 기호에 막대가 형성되어야 합니다.
다소 이렇습니다.
톨64 :
그리고 여기에서 주제의 첫 번째 게시물을 부주의하게 읽었음을 알 수 있습니다. 타이머 이벤트가 아니라 OnChartEvent ()입니다. 아니면 오타인가요?
왜 그래? 거기에 OnTimer 세 번째 숫자가 있습니다. 당신은 이미 이것에 대해 인용했습니다: 당신은 올바르게 테스트할 메소드를 구현하기만 하면 됩니다. 그는. 최소 간격의 OnTimer () 함수입니다. 따라서 다른 것을 생각해야 합니다.
톨64 :
EURUSD 가 하나 있지만 EA는 GBPUSD 에서 EURUSD 차트로 거래합니다. 그리고 결과도 똑같이 틀립니다.
이것이 당신에게 중요하다면 상위 5개에 있는 4중 fxt 파일의 유사체가 무엇인지 개발자와 함께 확인하는 것이 좋습니다. 나는 이미 다른 테스트에 대해 다른 틱 기반이 생성된다고 썼습니다.
어떤 현실을 말하는 겁니까? 실시간 테스트? 그렇다면 확실히 동의합니다. 두 명의 전문가를 기호에 매달면 모든 것이 정확할 것입니다. 하지만 다중 통화 모드를 테스트 중입니다. 그리고 OnTimer () 함수(10초)에서만 동일한 결과가 나타납니다.
다중 통화 모드(각 기호에 대해 설정된 Expert Advisors(각 Expert Advisor에서)의 N 기호에 대한 거래)에서의 실제 출시에 대해 이야기하고 있습니다. 이는 실제 평가를 제공하며 테스터의 경우 먼저 다중 통화 틱 처리 방법에서 각각의 올바른 작동이 아닌 테스트 모드 를 비교하십시오. 서로 다른 모드가 모두 테스터의 인공 환경을 기반으로 하는 경우 비교하는 의미가 무엇입니까? 실행 결과의 동일성은 거래 측면에서 가장 정확한 결과를 제공한다고 주장하는 근거를 제공하지 않으며 이것은 테스터의 내부 메커니즘 관점에서 최적입니다.
올바른 표현부터 시작하겠습니다. 원래 예에서는 "유로달러가 거래됨"을 원합니다. 실제로 사용자 이벤트 는 두 개의 기호에서 수신되었으며 이벤트 처리기에서는 이 두 기호 중 하나에서 이벤트가 수신될 때 TradeSignalCounter()+TradePerformer() 함수가 호출되었습니다. 이벤트 큐가 항상 한계까지 채워졌다고 가정할 수 있습니다.
이제 신호 소스 중 하나를 제거했지만 어떤 이유로 이벤트 핸들러에서 " if (sparam == Symbol_01)" 검사를 입력했습니다. 그러나 또 다른 질문은 다릅니다. 코드로 판단하면 "All ticks" 모드에서 Lizar의 방식을 사용하고 신호 소스(EURUSD)의 각 틱마다 TradeSignalCounter()+TradePerformer() 함수가 호출됩니다. 관심은 이미 이벤트 대기열의 오버플로 가능성에 대해 암시했습니다. 이 두 함수의 Symbol_01 매개변수로 어떤 도구를 사용하는지 궁금하며, Lizar의 방식에서 이벤트 빈도를 변경해 보셨습니까?
예, 싶었어요. 결국 우리의 모든 행동은 욕망에 의해 유발됩니다. 이 경우 내가 원하는 것을 정확히 얻었습니다. 즉, 심볼 배열의 각 심볼에 대한 TradePerformer () 함수에서 거래 허가를 확인하기 때문에 EURUSD 에서만 거래가 이루어졌습니다. 이 옵션은 외부 변수에 있으며 당시 GBPUSD 기호에 대한 거래가 금지되었습니다. 사용자 이벤트는 두 개의 기호에서 발생했지만 이벤트 핸들러에서 TradePerformer () 함수는 EURUSD 기호에서만 거래를 허용했습니다. TradePerformer () 함수에는 특정 기호(이 경우 EURUSD )에서 새로운 막대가 발생했는지 여부를 결정하는 함수도 포함되어 있습니다. 이벤트 대기열이 항상 가득 찼다는 가정은 정확했지만 이 경우 모든 것이 별도로 처리되었으며 일일 막대에서 테스트할 때 1틱 지연이 중요하지 않습니다.
테스트에 참여하지 말아야 할 하나의 신호 소스를 제거하면 모든 것이 이전에 올바르게 수행되었음을 확인할 수 있었습니다. " if (sparam == Symbol_01)" 테스트는 테스트해서는 안되지만 통과해야 하는 신호 소스를 제거하지 않고 결과를 확인할 때 남은 것입니다. 이 검사는 실제로 불필요한 것으로 판명되었습니다. 결과는 변경되지 않았습니다. Symbol_01 매개변수는 EURUSD 기호입니다. 이벤트 빈도를 변경하려고 시도했지만 아무 것도 변경되지 않았습니다. 더 정확히 말하면 올티키 모드가 가장 정확하다고 할 수 있다.
다중 통화 모드(각 기호에 대해 설정된 Expert Advisors(각 Expert Advisor에서)의 N 기호에 대한 거래)에서의 실제 출시에 대해 이야기하고 있습니다. 이는 실제 평가를 제공하며 테스터의 경우 먼저 테스트 모드 를 비교하고 각 다중 통화 틱 처리 방법의 올바른 작동이 아닙니다. 서로 다른 모드가 모두 테스터의 인공 환경을 기반으로 하는 경우 비교하는 의미가 무엇입니까? 실행 결과의 동일성은 거래 측면에서 가장 정확한 결과를 제공한다고 주장하는 근거를 제공하지 않으며 이것은 테스터의 내부 메커니즘 관점에서 최적입니다.
이제 명확해졌습니다. 그러나 처음에는 테스터에서 테스트하는 것에 대한 논의가 있었습니다. 결국, 거래를 시작하기 전에 시스템을 테스트해야 합니다. 그리고 테스트가 더 정확하게 수행될수록 실제 거래에서 더 큰 자신감을 느낄 것입니다. 제시된 테스트 결과는 정확하고 부정확하게 테스트할 수 있는 것을 보여줍니다. 이제 모든 사람이 선택권을 가지며 무엇이 옳고 그른지를 스스로 결정할 수 있습니다. 거래자 중 한 명이 매우 올바르게 말했습니다(내가 틀리지 않았다면 이것은 Van Tharp입니다): "우리는 우리의 아이디어로 거래합니다." 이 문장에 덧붙일 수 있습니다. 우리는 단순히 아이디어를 판매하지 않습니다. 우리는 심지어 우리의 생각으로만 살고 있습니다. ))
실제 거래나 테스트에서 각 기호에 전문가를 별도로 배치하면 이것이 가장 정확한 옵션이 될 것입니다. 나는 물론 이것에 동의합니다. 그러나 이를 위해 막대를 동기화할 필요가 없습니다. 정확성에는 지속 시간이 따릅니다. 테스터에서 긴 과거 기간을 평가할 수 있습니다. 그리고 개인적으로는 정확한 검사 결과를 보고 싶습니다.
한 가지만 더 말씀드리자면, 제가 어딘가에 실수할 가능성을 절대 배제하지 않고 항상 모든 것을 확인하고 있습니다. 그러나 가장 엄격한 검사를 거친 후에도 언뜻보기에는 모든 것이 괜찮아 보이지만 어딘가에 오류가있을 수 있음을 배제하지 않습니다. 현재 누군가가 제시된 테스트 방법의 결과 평가에 동의하지 않으면 테스트 결과를 비교하여 제공해야 합니다. 결국 이 스레드의 목적은 올바르게 수행하는 방법, 또는 더 정확하게는 다중 통화 Expert Advisors를 올바르게 테스트하는 방법을 찾는 것입니다. 말로만 옳고 그름은 아닙니다. 팩트, 팩트만 팩트, 팩트만! )))
서로 다른 모드가 모두 테스터의 인공 환경을 기반으로 하는 경우 비교하는 의미가 무엇입니까?
요점은 얻은 결과에 따라 올바른 결정을 내리는 것입니다. 하지만 왜곡된 데이터를 분석하는 데에는 아무런 의미가 없습니다. 결국 뿌린 대로 거둡니다.
테스트에 참여하지 말아야 할 하나의 신호 소스를 제거하면 모든 것이 이전에 올바르게 수행되었음을 확인할 수 있었습니다.
"... 그 전에 모든 것이 올바르게 완료되었습니다." - 이것은 안일함의 범주에 속합니다. 처음에는 틀렸습니다. 분명히 당신은 "이벤트 대기열의 오버플로"와 같은 현상을 중요하게 생각하지 않습니다. 특히 틱으로 이벤트를 전송할 때. 이 주제에 대한 도움말 자료와 포럼을 살펴보십시오. 키워드는 "대기열"입니다.
... 기호 배열의 각 기호에 대한 TradePerformer () 함수에 거래 허가 확인이 있기 때문에 거래는 EURUSD 에서만 수행되었습니다. 이 옵션은 외부 변수에 있으며 당시 GBPUSD 기호에 대한 거래가 금지되었습니다. 사용자 이벤트 는 두 개의 기호에서 발생했지만 이벤트 핸들러에서 TradePerformer () 함수는 EURUSD 기호에서만 거래를 허용했습니다. TradePerformer () 함수에는 특정 기호(이 경우 EURUSD )에서 새로운 막대가 발생했는지 여부를 결정하는 함수도 포함되어 있습니다. 이벤트 대기열이 항상 가득 찼다는 가정은 정확했지만 이 경우 모든 것이 별도로 처리되었으며 일일 막대에서 테스트할 때 1틱 지연이 중요하지 않습니다.
TradeSignalCounter()+TradePerformer() 함수가 하나의 신호 소스에서만 이벤트를 처리했다는 사실은 이벤트 큐의 상태와 가능한 오버플로를 변경하지 않았습니다. 즉, "GBRUSD 기호에 대한 이벤트 처리 금지"는 이벤트 대기열에서 해당 이벤트를 전혀 제거하지 않았습니다. 세 번째로 저는 문제에 주의를 기울였습니다. "관심은 이미 이벤트 대기열의 오버플로 가능성에 대해 암시했습니다." :) 우리가 "한 틱 지연"에 대해 이야기하고 있다고 생각한다면 그러한 결론은 무엇을 기반으로 합니까?
"...이 경우 모든 것이 별도로 처리되었습니다." 문제는 원래 버전에서 이벤트 핸들러가 두 신호 소스에서 이벤트를 수신할 때 함수를 호출한 다음 이러한 함수가 "불필요한" 소스에서 신호를 필터링했다는 것입니다. 그러나 함수는 (!) 시간마다 호출되었습니다.
일일 막대에서 테스트할 때 1틱 지연은 중요하지 않습니다.
예, 이벤트 핸들러가 테스트되는 기간은 중요하지 않습니다. Lizar의 계획이 틱당 신호를 생성하면 하루에 한 번이 아니라 틱당 이벤트 대기열을 채웁니다.
"이벤트 빈도를 변경해 보았지만 달라지는 것은 없었습니다. 정확히는 올틱 모드가 가장 정확하다고 할 수 있습니다." Lizar의 비틱 모드에 대한 비교 스크린샷을 제공할 수 있습니까?
실제 거래나 테스트에서 각 기호에 전문가를 별도로 배치하면 이것이 가장 정확한 옵션이 될 것입니다. 나는 물론 이것에 동의합니다. 그러나 이를 위해 막대를 동기화할 필요가 없습니다. 정확성에는 지속 시간이 따릅니다. 테스터에서 긴 과거 기간을 평가할 수 있습니다. 그리고 개인적으로는 정확한 검사 결과를 보고 싶습니다.
요점은 얻은 결과에 따라 올바른 결정을 내리는 것입니다. 하지만 왜곡된 데이터를 분석하는 데에는 아무런 의미가 없습니다. 결국 뿌린 대로 거둡니다.
"정확성" 범주가 이제 테스터 실행 ID로 대체되었다는 점을 지적하려고 합니다. 그러나 그렇다고 해서 그러한 데이터가 덜 왜곡된 것은 아닙니다. 특히, 이제 10초 간격을 선택했는데 의심할 여지 없이 5초 또는 1초 간격보다 더 많이 데이터를 왜곡합니다. 저것들. 10초 타이머로 선호하는 방법을 제공하는 테스터 환경의 기능을 활용하고 있습니다. 사실, 타이머 이벤트가 있는 모든 악기에 새 막대의 틱이 도착 하는 순간을 "잡으려고" 하고 있으며 이를 수행하는 가장 좋은 방법은 OnTick 이벤트입니다.
시간을 낭비하지 마십시오. 틱에서 완전한 일치를 달성할 수 없습니다. 바의 닫는 시간은 악기마다 다르며 악기마다 다릅니다.
기기에서 현재 시간은 막대 닫는 시간입니다. 두 번째 막대는 아직 형성되지 않았으며 세 번째 막대는 몇 틱 전에 이미 형성되었습니다.
틱 기록 을 보면 틱 볼륨은 때때로 기기마다 다릅니다.
Yedelkin 2011.08.25 08:16 #
"... 그 전에 모든 것이 올바르게 완료되었습니다." - 이것은 안일함의 범주에 속합니다.
---
좋은 아침! ))
이 문구 외에도 텍스트와 별도로 찢어서 다음과 같이 썼습니다. "... 나는 어딘가에서 실수 한 것을 배제하지 않고 항상 모든 것을 확인합니다. 그러나 가장 엄격한 검사 후에도 모든 것이 언뜻보기에 올바르게 보일 때 , 나는 여전히 어딘가에 버그가 있을 수 있다는 것을 배제하지 않습니다 . 나는 모든 것에 대해 항상 옳다고 생각하는 사람들의 범주에 속하지 않는다고 덧붙일 것입니다. )))
---
예델킨:
처음에는 틀렸습니다. 분명히 당신은 "이벤트 대기열의 오버플로"와 같은 현상을 중요하게 생각하지 않습니다. 특히 틱으로 이벤트를 전송할 때. 이 주제에 대한 도움말 자료와 포럼을 살펴보십시오. 키워드는 "대기열"입니다.
---
나는 Timer 라는 주제를 보았다. 강조 표시된 핵심 사항은 다음과 같습니다.
1. 하나의 이벤트를 처리하는 동안 다른 이벤트를 처리할 수 없습니다.
2. 이벤트 스택이 오버플로되면 오래된 이벤트는 처리 없이 대기열에서 제거됩니다.
순서대로 가자. 이벤트 목록이 있습니다.
초기화하는 동안 이벤트를 수신할 기호와 수신할 이벤트를 나타냅니다.
즉, EURUSD 기호에서만 CHARTEVENT_TICK 이벤트를 수락합니다. 다른 캐릭터는 없습니다.
테스트가 시작되었습니다. 이벤트가 발생하면 프로그램은 OnChartEvent () 함수를 입력하고 거래 신호에 대한 변수 배열을 선언하고 이벤트가 무엇인지 확인합니다. 이것이 사용자 정의 이벤트인 경우 프로그램은 TradeSignalCounter()에서 신호를 정의한 다음 TradePerformer ( ) 함수에서 새 막대가 도착했는지 여부를 확인하고 이에 따라 다른 조건을 결정합니다. 함수는 작업을 완료했으며 EURUSD 차트에서 이벤트가 발생한 후에만 시작됩니다. 이 경우 틱입니다.
예델킨:
TradeSignalCounter() + TradePerformer ( ) 함수가 하나의 신호 소스에서만 이벤트를 처리했다는 사실은 이벤트 큐의 상태와 가능한 오버플로를 변경하지 않았습니다. 즉, " GBRUSD 기호에 대한 이벤트 처리 금지"는 이벤트 대기열에서 해당 이벤트를 전혀 제거하지 않았습니다. 세 번째로 저는 문제에 주의를 기울였습니다. "관심은 이미 이벤트 대기열의 오버플로 가능성에 대해 암시했습니다." :) 우리가 "한 틱 지연"에 대해 이야기하고 있다고 생각한다면 그러한 결론은 무엇을 기반으로 합니까?
---
이러한 기능의 실행은 매우 빠릅니다. 이벤트 대기열은 오버플로할 시간이 없으며 중요한 이벤트를 놓치지 않습니다. 그리고 대기열이 오버플로되고 이벤트가 건너뛴다면 무엇을 놓치게 될까요? 똑딱, 둘, 셋? 글쎄요? 이것은 일일 바에서 무시할 수 있습니다.
---
예델킨:
문제는 원래 버전에서 이벤트 핸들러가 두 신호 소스에서 이벤트를 수신할 때 함수를 호출한 다음 이러한 함수가 "불필요한" 소스에서 신호를 필터링했다는 것입니다. 그러나 함수는 (!) 시간마다 호출되었습니다.
---
왜이 두 번째 소스에 집착합니까.))) 더 이상 두 번째 소스가 없습니다. EURUSD 가 하나 있지만 EA는 GBPUSD 에서 EURUSD 차트로 거래합니다. 그리고 결과도 똑같이 틀립니다. 복사. 즉, 두 번째 소스가 있는 것과 동일합니다. )))
-----------
테스트를 직접 해보고, 테스트 결과를 보여주고, 당신이 할 수 있다면 정확한 테스트 결과를 얻기 위해 무엇을 했는지 (간단히) 쓰는 것이 좋습니다. 가장 간단한 Expert Advisor가 이 테스트에 적합합니다. 모든 조건에 의한 진입, 손절매, 이익실현. 지난 10년 동안 매일 바를 보자. 그리고 당신 자신이 직접 보게 될 것입니다. 일부는 일치하고 일부는 일치하지 않습니다. 결과 그래프를 열고 불일치가 있는 위치를 확인합니다.
막대를 온라인으로 동기화할 필요가 없는 이유는 무엇입니까?!
당신이 그 전에 썼기 때문에:
마케터 :
다중 통화 모드(각 기호에 설정된 EA(각 EA)의 N 기호에 대한 거래)에서의 실제 실행에 대해 이야기하고 있습니다. 이는 실제 추정치를 제공합니다.
이를 통해 실제 출시란 여러 Expert Advisor가 출시되고 각각이 고유한 기호에 직접 매달릴 때 온라인 테스트를 의미한다는 것을 이해했습니다. 그것이 당신이 의미하는 바라면 질문은 다음과 같습니다. 이 경우 각 Expert Advisor가 고유한 기호에 매달리는 경우 막대를 동기화해야 하는 이유는 무엇입니까? 거래 시스템이 한 번에 여러 기호에 대해 결정이 내려지는 방식으로 설계된 경우 이 경우 막대의 동기화가 필요할 수 있으므로 이러한 여러 기호에 막대가 형성되어야 합니다. 하나의 심볼(모든 심볼에 대해)에 있는 동안 여러 심볼에 대한 독립적인 거래를 의미합니다.
마케터 :
테스터의 이러한 모든 실험은 온라인 거래를 평가하기 위해 필요하며, 이 주제의 문제는 테스터(온라인을 에뮬레이트하는)가 아닌 온라인의 문제에 있으며, 무엇보다도 온라인에서 막대의 동기화가 필요합니다. 해당 전문가 고문).
저에게 있어 히스토리 거래의 결과를 평가하기 위해서는 테스터에서의 실험이 필요합니다. 그리고 온라인 거래에 대한 나의 선택은 이 평가에 달려 있습니다. 따라서 이 주제의 문제는 온라인이 아닌 테스터의 문제에 있으며, 그렇기 때문에 테스터에서도 막대의 동기화가 필요합니다(관련 전문가의 경우). 일종의 거울 이미지.
마케터 :
"정확성" 범주가 이제 테스터 실행 ID로 대체되었음을 지적하려고 합니다. 그러나 그렇다고 해서 그러한 데이터가 덜 왜곡된 것은 아닙니다. 특히, 이제 10초 간격을 선택했는데 의심할 여지 없이 5초 또는 1초 간격보다 더 많이 데이터를 왜곡합니다. 저것들. 10초 타이머로 선호하는 방법을 제공하는 테스터 환경의 기능을 활용하고 있습니다.
예, 간격이 작을수록 결과가 더 정확합니다. 그러나 사실, 그것은 적어도 나에게는 마지막 시험에 필요합니다. 그리고 예비의 경우 1분 간격이면 충분하다는 Vladimir( MetaDriver )의 의견에 여전히 동의합니다.
마케터 :
사실, 타이머 이벤트가 있는 모든 악기에 새 막대의 틱이 도착 하는 순간을 "잡으려고" 하고 있으며 이를 수행하는 가장 좋은 방법은 OnTick 이벤트입니다.
그리고 여기에서 주제의 첫 번째 게시물을 부주의하게 읽었음을 알 수 있습니다. 타이머 이벤트가 아니라 OnChartEvent ()입니다. 아니면 오타인가요?
이를 통해 실제 출시란 여러 Expert Advisor가 출시되고 각각이 고유한 기호에 직접 매달릴 때 온라인 테스트를 의미한다는 것을 이해했습니다. 그것이 당신이 의미하는 바라면 질문은 다음과 같습니다. 이 경우 각 Expert Advisor가 고유한 기호에 매달리는 경우 막대를 동기화해야 하는 이유는 무엇입니까? 거래 시스템이 한 번에 여러 기호에 대해 결정이 내려지는 방식으로 설계된 경우 이 경우 막대의 동기화가 필요할 수 있으므로 이러한 여러 기호에 막대가 형성되어야 합니다.
다소 이렇습니다.
그리고 여기에서 주제의 첫 번째 게시물을 부주의하게 읽었음을 알 수 있습니다. 타이머 이벤트가 아니라 OnChartEvent ()입니다. 아니면 오타인가요?
왜 그래? 거기에 OnTimer 세 번째 숫자가 있습니다. 당신은 이미 이것에 대해 인용했습니다: 당신은 올바르게 테스트할 메소드를 구현하기만 하면 됩니다. 그는. 최소 간격의 OnTimer () 함수입니다. 따라서 다른 것을 생각해야 합니다.
EURUSD 가 하나 있지만 EA는 GBPUSD 에서 EURUSD 차트로 거래합니다. 그리고 결과도 똑같이 틀립니다.
이것이 당신에게 중요하다면 상위 5개에 있는 4중 fxt 파일의 유사체가 무엇인지 개발자와 함께 확인하는 것이 좋습니다. 나는 이미 다른 테스트에 대해 다른 틱 기반이 생성된다고 썼습니다.