첫째, TS는 이상적인 거래 조건이 있는 테스터를 위해 작성되었습니다. 모든 것이 정상이면 실제 생활에서 테스터에서 보는 것과 최대한 유사한 방식으로 전투 버전을 작성하려고 합니다. TS를 작성하는 다른 접근 방식은 아이디어의 알고리즘화가 아니라 아마도 일뿐입니다.
따라서 근본적인 질문은 테스터에게 가장 가까운 전투 상황은 무엇입니까? 나는 내 의견을 말하고 (예를 들어) 당신의 말을 들었습니다.
또한 가장 정확한 번역의 문제에 직면했습니다. 테스트에서 전문가의 거래 논리 실제 계정에서 작업하려면 전략 테스터 (MT4)의 눈금에 표시합니다.
내 추론:
전문가는 테스터에서 작동 이상적인 거래 조건뿐만 아니라 실제로 다른 모드에서 - 즉, 실시간으로 한 틱에서 그는 그곳에서 TS를 계산하고 주문을 보내고 이에 대한 응답을 받지만 거래 계정에서 실제로 사용하면 더 이상 그렇지 않습니다. 그것은 밝혀 우리는 두 개의 서로 다른 로봇을 가지고 있습니다 - 하나는 실시간이고 다른 하나는 실시간이 아닙니다. 보내기/수정 주문(하나라도!) 실제 계정으로 = ping + 실행 시간 등 = 기껏해야 100-500ms이고 이때 진드기가 있고 계산해야 합니다. 그리고 우리는 서서 기다리며 ... 그런 다음 임의의 순서로 흐름으로 팽창합니다(이 시간에 가격은 상대적으로 어디로 갔습니까? 우리의 틱 평균에 x.z. + 우리는 아마도 가장 빠르고 일반적으로 가장 중요한 틱 중 일부를 놓쳤을 것입니다). 결과적으로 테스터에서 롤백한 전략에서 아무것도 남길 수 없는 것으로 나타났습니다.
그래서 곰곰이 생각해 보니 다음과 같은 결론이 나왔다.
전투 모드에서 Expert Advisor의 거래 논리는 비활성화되며 본질적으로 복사기로 작동합니다.
트레이딩 시스템은 인디케이터로 이전되어 오픈 및 클로징 명령을 생성하고 Expert Advisor가 이러한 명령을 실행할 때까지 기다리지 않고 단순히 실행합니다. 이상적으로 그것에 포함된 차량 테스터와 거의 같은 조건. 내가 아는 한, 표시기는 틱을 건너뛰어서는 안 되지만 기술적으로 가능한지 의심스럽습니다. 그러나 적어도 처음에 이 기능이 있고 설명서에 설명되어 있는 Expert Advisor보다 적은 틱을 건너뛰어야 합니다. + 계산오차를 분리하여도 TS가 작아야 한다. TS의 논리에 부차적인 작업에 대한 작업 중단이 없습니다.
전투 모드에서 Expert Advisor의 거래 논리는 비활성화되며 본질적으로 복사기로 작동합니다.
트레이딩 시스템은 인디케이터로 이전되어 오픈 및 클로즈 명령이 생성되며, 이러한 명령이 전문가에 의해 실행될 때까지 기다리지 않고 단순히 실행됩니다. 이상적으로 그것에 포함된 차량 테스터와 거의 같은 조건. 내가 아는 한, 표시기는 틱을 건너뛰어서는 안 되지만 기술적으로 가능한지 의심스럽습니다. 그러나 적어도 처음에 이 기능이 있고 설명서에 설명되어 있는 Expert Advisor보다 적은 틱을 건너뛰어야 합니다. + 계산오차를 분리하여도 TS가 작아야 한다. TS의 논리에 부차적인 작업에 대한 작업 중단이 없습니다.
예, 저는 동일한 접근 방식을 사용합니다. 일종의 내부 이상 테스터로서 자체 공개 주문과 이러한 가상 주문을 구체화하려는 복사기를 사용합니다. 이러한 계획은 많은 무거운 함정을 쉽게 우회합니다.
MT5에서는 더 쉽습니다. 거기에서 틱 기록 을 요청할 수 있습니다. 그리고 여러 악기에 대해.
그것은 시간에 관한 것이 아니라 논리에 관한 것입니다(시간에 관한 - 이것은 다른 스레드에 있습니다 ;-)). 당신의 논리(그리고 내 논리는 자동차 비유를 포함하여 모든 것에 동의하기 때문에)는 환경을 부분적으로가 아니라 "일단 급습하고 전체적으로" 분석하는 것입니다. 부작용 처리가 다음 호출까지 지연되기 때문입니다. 이러한 효과는 새로운 거래 환경에 구축됩니다.
글쎄, 시간에 대한 수정이 없다면 두 논리(내 논리와 fxsaber 모두)가 동일할 것입니다. 모든 주문은 여러 오류 후에도 매 틱마다 처리됩니다.
과제는 테스트 중에 얻은 이상적인 모델에 더 가까운 비 순간 실행으로 현실을 가져 오는 것입니다.
OOP 예제를 기대합니다. 그리고 나는 그것을 순환의 형태로 동일한 중추로 봅니다. 먼저 변경해야 할 사항을 결정한 다음 이미 내린 결정에 따라 논리가 변경되지 않는다는 사실에서.
특히 이 작업에 대해서는 예제를 작성하지 않겠습니다. 그러나 접근 방식의 단순화된 개념은 내 블로그 에서 볼 수 있습니다. 거기에서 대기열은 깊이 분석되지 않고 비어 있는지만 확인됩니다. 원하는 사람은 개선할 수 있습니다.
논리적으로 "변경된 가격에 맞게 주문 묶음 수정"이라는 전체 작업을 의미한다면 하나만 있습니다. 문제는 구현할 때 모든 주문을 수정하거나 최신 가격 으로 수정하는 것이 더 중요합니다. 기본 설정에 따라 여기의 논리가 이미 다릅니다. 간단한 루프는 모든 주문이 업데이트되도록 하며 저는 이 옵션을 선호합니다. 이미 언급했듯이 OOP는 작업을 책임 블록으로 분할하는 가시성을 제공하며 이러한 분해를 기반으로 "모든 주문"이 "가격 관련성"보다 더 중요합니다. 가격이 끊임없이 변하고 주문이 가끔 있다는 점을 감안해도 이것은 분명합니다. 그것들이 더 중요합니다.
다음 주제는 MT4뿐만 아니라 다른 플랫폼과의 MT5에 관한 것입니다. 그러나 쉽게 인식할 수 있도록 이 스레드에서 논리를 MQL4로 작성합니다.
대부분의 경우 주문 수정/삭제의 백본(성장)은 다음 논리로 귀결됩니다.
이제 접근 방식은 드물지만 훨씬 더 정확합니다.
거래 요청 을 보낸 후 거래 환경이 바뀌므로 거래 서버의 응답 직후 TS의 모든 거래 로직을 처음부터 처음부터 실행하는 것이 좋습니다.
루핑은 가장 위험한 프로그래밍 기술 중 하나입니다. 분석하기가 거의 불가능한 이상하고 드물게 나타나는 오류로 가득 차 있습니다.
반복하는 대신 반대로 사용자 스레드를 가능한 한 빨리 완료하도록 해야 합니다. 당신이 정말로 "맥박"을 유지하고 싶다면 - MT5에서 OnTradeTransaction을 분석하십시오. MT4는 일반적으로 그러한 단점에 좋지 않습니다. 왜냐하면 단순함이 절도보다 더 나쁘기 때문입니다.
그녀는 그렇지 않을 것입니다. 강하지 않다.
첫째, TS는 이상적인 거래 조건이 있는 테스터를 위해 작성되었습니다. 모든 것이 정상이면 실제 생활에서 테스터에서 보는 것과 최대한 유사한 방식으로 전투 버전을 작성하려고 합니다. TS를 작성하는 다른 접근 방식은 아이디어의 알고리즘화가 아니라 아마도 일뿐입니다.
따라서 근본적인 질문은 테스터에게 가장 가까운 전투 상황은 무엇입니까? 나는 내 의견을 말하고 (예를 들어) 당신의 말을 들었습니다.
또한 가장 정확한 번역의 문제에 직면했습니다. 테스트에서 전문가의 거래 논리 실제 계정에서 작업하려면 전략 테스터 (MT4)의 눈금에 표시합니다.
내 추론:
전문가는 테스터에서 작동 이상적인 거래 조건뿐만 아니라 실제로 다른 모드에서 - 즉, 실시간으로 한 틱에서 그는 그곳에서 TS를 계산하고 주문을 보내고 이에 대한 응답을 받지만 거래 계정에서 실제로 사용하면 더 이상 그렇지 않습니다. 그것은 밝혀 우리는 두 개의 서로 다른 로봇을 가지고 있습니다 - 하나는 실시간이고 다른 하나는 실시간이 아닙니다. 보내기/수정 주문(하나라도!) 실제 계정으로 = ping + 실행 시간 등 = 기껏해야 100-500ms이고 이때 진드기가 있고 계산해야 합니다. 그리고 우리는 서서 기다리며 ... 그런 다음 임의의 순서로 흐름으로 팽창합니다(이 시간에 가격은 상대적으로 어디로 갔습니까? 우리의 틱 평균에 x.z. + 우리는 아마도 가장 빠르고 일반적으로 가장 중요한 틱 중 일부를 놓쳤을 것입니다). 결과적으로 테스터에서 롤백한 전략에서 아무것도 남길 수 없는 것으로 나타났습니다.
그래서 곰곰이 생각해 보니 다음과 같은 결론이 나왔다.
그래서 곰곰이 생각해 보니 다음과 같은 결론이 나왔다.
예, 저는 동일한 접근 방식을 사용합니다. 일종의 내부 이상 테스터로서 자체 공개 주문과 이러한 가상 주문을 구체화하려는 복사기를 사용합니다. 이러한 계획은 많은 무거운 함정을 쉽게 우회합니다.
MT5에서는 더 쉽습니다. 거기에서 틱 기록 을 요청할 수 있습니다. 그리고 여러 악기에 대해.
그것은 시간에 관한 것이 아니라 논리에 관한 것입니다(시간에 관한 - 이것은 다른 스레드에 있습니다 ;-)). 당신의 논리(그리고 내 논리는 자동차 비유를 포함하여 모든 것에 동의하기 때문에)는 환경을 부분적으로가 아니라 "일단 급습하고 전체적으로" 분석하는 것입니다. 부작용 처리가 다음 호출까지 지연되기 때문입니다. 이러한 효과는 새로운 거래 환경에 구축됩니다.
글쎄, 시간에 대한 수정이 없다면 두 논리(내 논리와 fxsaber 모두)가 동일할 것입니다. 모든 주문은 여러 오류 후에도 매 틱마다 처리됩니다.
과제는 테스트 중에 얻은 이상적인 모델에 더 가까운 비 순간 실행으로 현실을 가져 오는 것입니다.
예, 동일한 접근 방식을 사용합니다. 일종의 내부 이상 테스터로서 자체적인 공개 주문과 이러한 가상 주문을 구체화하려고 시도하는 복사기를 사용합니다.
접근 방식을 구체화하면(주기에서 현실과 성공적으로 동기화될 때까지 첫 번째 순서를 유지함) 다른 주문에 대해 시력을 잃는(또는 나중에 처리하는) 동일한 문제에 직면할 수 있습니다. 그러나 이것은 완료된 것으로 추정되는 동일한 주제에 관한 것입니다)
접근 방식을 구체화하면(주기에서 현실과 성공적으로 동기화될 때까지 첫 번째 순서를 유지함) 다른 주문에 대해 시력을 잃는(또는 나중에 처리하는) 동일한 문제에 직면할 수 있습니다. 그러나 이것은 완료된 것으로 추정되는 동일한 주제에 관한 것입니다)
이것이 우리가 거래하는 방법입니다!
OOP 예제를 기대합니다. 그리고 나는 그것을 순환의 형태로 동일한 중추로 봅니다. 먼저 변경해야 할 사항을 결정한 다음 이미 내린 결정에 따라 논리가 변경되지 않는다는 사실에서.
특히 이 작업에 대해서는 예제를 작성하지 않겠습니다. 그러나 접근 방식의 단순화된 개념은 내 블로그 에서 볼 수 있습니다. 거기에서 대기열은 깊이 분석되지 않고 비어 있는지만 확인됩니다. 원하는 사람은 개선할 수 있습니다.
논리적으로 "변경된 가격에 맞게 주문 묶음 수정"이라는 전체 작업을 의미한다면 하나만 있습니다. 문제는 구현할 때 모든 주문을 수정하거나 최신 가격 으로 수정하는 것이 더 중요합니다. 기본 설정에 따라 여기의 논리가 이미 다릅니다. 간단한 루프는 모든 주문이 업데이트되도록 하며 저는 이 옵션을 선호합니다. 이미 언급했듯이 OOP는 작업을 책임 블록으로 분할하는 가시성을 제공하며 이러한 분해를 기반으로 "모든 주문"이 "가격 관련성"보다 더 중요합니다. 가격이 끊임없이 변하고 주문이 가끔 있다는 점을 감안해도 이것은 분명합니다. 그것들이 더 중요합니다.
OOP는 작업을 책임 블록으로 나누는 것에 대한 가시성을 제공하며 이러한 분해를 기반으로 "가격 관련성"보다 "모든 주문"이 더 중요합니다.
이 분해 에 기초하여 나눗셈만이 뒤따른다. 이러한 OOP가 있는 "가격 관련성"은 대기열에 한 자리를 설정함으로써 달성됩니다.
이것은 일종의 "철학"이 사라졌습니다. 처리는 대안에서 제안된 것처럼 틱 흐름이 아닌 순서대로 수행됩니다. 일반적으로 나는 이 토론에서 제외됩니다. 모든 주장은 이미 제시되었습니다.
일반적으로 나는 이 토론에서 제외됩니다. 모든 주장은 이미 제시되었습니다.
이미 이런 식으로 끝내는 추세입니다.
다음 주제는 MT4뿐만 아니라 다른 플랫폼과의 MT5에 관한 것입니다. 그러나 쉽게 인식할 수 있도록 이 스레드에서 논리를 MQL4로 작성합니다.
대부분의 경우 주문 수정/삭제의 백본(성장)은 다음 논리로 귀결됩니다.
이제 접근 방식은 드물지만 훨씬 더 정확합니다.
거래 요청 을 보낸 후 거래 환경이 바뀌므로 거래 서버의 응답 직후 TS의 모든 거래 로직을 처음부터 처음부터 실행하는 것이 좋습니다.
루핑은 가장 위험한 프로그래밍 기술 중 하나입니다. 분석하기가 거의 불가능한 이상하고 드물게 나타나는 오류로 가득 차 있습니다.
반복하는 대신 반대로 사용자 스레드를 가능한 한 빨리 완료하도록 해야 합니다. 당신이 정말로 "맥박"을 유지하고 싶다면 - MT5에서 OnTradeTransaction을 분석하십시오. MT4는 일반적으로 그러한 단점에 좋지 않습니다. 왜냐하면 단순함이 절도보다 더 나쁘기 때문입니다.