생각의 교환/상호 학습을 위해, 나는 다소 실용적인 문제처럼 보이는 (손가락에서 빨아) 전체 집단 농장과 그것을 구성하는 것을 제안합니다.
예를 들어, 최소한 그러한 작업에 대한 기본 구조(더 정확하게는 이러한 구조의 변형)에 대한 개요를 작성하십시오.
어쨌든 서면 고문이 있습니다(예: 거래 아이디어를 테스트하기 위해). 테스터(고객)의 아이디어가 유망한 결과를 보였다고 가정합니다. 이제 어드바이저를 개발에 편리한 형태로 가져오려면 어드바이저를 다시 작성해야 합니다. 특히 그래픽 사용자 제어판을 제공합니다 .
테스터에서 최적화를 위해 패널을 비활성화하거나 Expert Advisor의 전체 "비그래픽" 구현을 그래픽 인터페이스에 연결할 수 있는 포함된 파일(.mqh)로 이동하는 것이 바람직합니다. "테스트" 및 " 그래픽" 버전 작동의 차이점 없이 (제외하기 위해).
그러한 프로젝트를 구성하는 데 대한 고려 사항을 듣고 읽고 싶습니다. 특히, 그러한 프로젝트에서 이벤트 관리 모델의 구현에 대해. 이중 구현(테스트 + 패널)이 고객의 엄격한 요구 사항이라고 가정합니다(즉, 어떤 방식으로든 수행해야 하며 구현 방법만 선택할 수 있음).
퍼즐을 풀어볼까요?
전문가의 제어판과 전문가 자체가 같은 프로그램의 완전히 다른 두 모듈이라는 것은 자명하다고 생각합니다. 따라서 이러한 각 부분이 서로 독립적인 방식으로 이들을 분리해야 합니다. 즉, Expert Advisor의 일부를 변경할 때(예: 주문 논리 변경) 패널의 논리를 변경할 필요가 없었으며 그 반대의 경우도 마찬가지입니다(패널의 인터페이스를 변경했습니다. Expert Advisor의 논리를 변경할 필요 없음). 가장 먼저 떠오르는 것은 패널과 전문가가 데이터를 교환 할 수 있는 통합 인터페이스의 생성이다. 그러나 불행히도 MQL5의 작성자는 수평 링크 생성 가능성을 제공하지 않았습니다. 즉, MQL5 도구를 사용하여 둘 사이의 인터페이스를 설명하는 것이 불가능합니다. 그런 다음 수직 통합의 경로가 있습니다. Expert Advisor는 패널과 상호 작용하기에 충분한 메서드와 데이터를 포함하는 기본 클래스에서 상속되어야 합니다. 이는 기본 조언에서 상속된 모든 Expert Advisor도 패널을 표시하고 상호 작용할 수 있는 기능을 획득함을 의미합니다. 동시에 패널과의 상호작용을 담당하는 메소드의 구현은 자손에게 위임되어서는 안 되며, 기본 클래스의 뒤에서 수행되어야 합니다. "후손! 패널로 작업하려면 매개변수를 사용하여 내 메서드를 호출하세요."라는 메시지가 전혀 작동하지 않습니다. 이상적으로는 기본 클래스에서 상속된 파생된 Expert Advisor가 편리한 방식으로 거래되어야 하며 해당 작업이 이 패널에 자동으로 표시됩니다.
보편적인 기본 거래 클래스를 구성하는 방법은 별개의 흥미로운 주제입니다. 이 문제에 대한 몇 년 간의 연습은 마침내 저를 개인적으로 보편적인 계획으로 이끌었습니다. 그것은 투명하고 보편적인 것으로 밝혀졌습니다. 관심이 있으시면 그녀에게 기본 순서도를 줄 수 있습니다(하하, 순서도를 그리는 것은 여전히 유용한 연습입니다). 그러나 어쨌든 모든 사람은 자신의 방식을 가지고 있으며 한 사람에게 좋은 해결책이 다른 사람에게 좋은 해결책이 될 수는 없습니다.
1. 가장 먼저 떠오르는 것은 패널과 전문가가 데이터를 교환할 수 있는 통일된 인터페이스의 생성이다.
2. 불행히도 MQL5의 작성자는 수평 링크 생성 가능성을 제공하지 않았습니다. 즉, MQL5 도구를 사용하여 둘 사이의 인터페이스를 설명하는 것이 불가능합니다.
1. 확실히.
2. 글쎄, 왜 안되지? 맞춤 이벤트는 어떻습니까? 상당히 수평적이고 보편적입니다.
3. 그 다음은 수직적 통합의 길입니다. Expert Advisor는 패널과 상호 작용하기에 충분한 메서드와 데이터를 포함하는 기본 클래스에서 상속되어야 합니다. 이는 기본 조언에서 상속된 모든 Expert Advisor도 패널을 표시하고 상호 작용할 수 있는 기능을 획득함을 의미합니다. 동시에 패널과의 상호작용을 담당하는 메소드의 구현은 자손에게 위임되어서는 안 되며, 기본 클래스의 뒤에서 수행되어야 합니다. "후손! 패널로 작업하려면 매개변수를 사용하여 내 메서드를 호출하세요."라는 메시지가 전혀 작동하지 않습니다. 이상적으로는 기본 클래스에서 상속된 파생된 Expert Advisor가 편리한 방식으로 거래되어야 하며 해당 작업이 이 패널에 자동으로 표시됩니다.
3. 2항에 동의하지 않기 때문에 이 옵션은 아직 파지 않습니다.
--
내가 아주 좋아하는 옵션이 있습니다. ("전환 가능한" 패널이 있는 옵션). 패널을 표시기처럼 보이게 합니다. 전문가가 테스터에 있으면 패널을 로드하지 않습니다. 추가 보너스는 패널이 다른 스레드에서 실행되어 전문가에게 더 많은 리소스를 제공한다는 것입니다.
패널의 다양성에 관해서. 패널이 ini-file을 사용하여 완전히 구성되었다는 사실에 대한 근본적인 장애물은 보이지 않습니다. 저것들. 거기에서 사용자와 상호 작용할 때 생성해야 하는 제한된 고정 시각적 구성 요소 + 이벤트 코드 집합에서 패널을 만드는 데 필요한 모든 데이터를 절대적으로 작성할 수 있습니다.
보편적인 기본 거래 클래스를 구성하는 방법은 별개의 흥미로운 주제입니다. 이 문제에 대한 몇 년 간의 연습은 마침내 저를 개인적으로 보편적인 계획으로 이끌었습니다. 그것은 투명하고 보편적인 것으로 밝혀졌습니다. 관심이 있다면 그녀에게 개략적인 블록 다이어그램을 줄 수 있습니다. ....
할 수 있습니다. 나는 심지어 매우 관심이 있습니다. 예, 실질적으로 유용할 수 있습니다.
할 수 있습니다. 나는 심지어 매우 관심이 있습니다. 예, 실질적으로 유용할 수 있습니다.
파란색 프레임 - 기본 클래스 엔터티. 파생 클래스 엔터티의 빨간색 테두리입니다. 기본 클래스가 네 가지 메서드로 논리 정의를 자식에게 부과한다는 것을 알 수 있습니다. 모든 전략에 대한 설명을 단 4가지 상황에 대한 설명으로 줄이는 것은 이 방법입니다.
1. 롱포지션을 열기 위한 모든 규칙이 충족되면 InitBuy() 메서드에서 롱포지션이 열립니다.
2. 롱 포지션 청산에 대한 모든 규칙이 충족되면 SupportBuy() 메소드에서 롱 포지션이 청산됩니다.
3. 매도 포지션 개설에 대한 모든 규칙이 충족되면 InitSell() 메서드에서 매도 포지션이 열립니다.
4. 숏 포지션 청산에 대한 모든 규칙이 충족되면 SupportSell() 메서드에서 숏 포지션이 청산됩니다.
이 논리에 따르면 전략의 반전은 하나의 방법(예: 매수 매도, 매도 매도)이 아니라 서로 독립적인 두 가지 방식으로 설명됩니다. 이 접근 방식은 매우 편리하기 때문에 밝혀졌습니다. 예를 들어 클릭 한 번으로 기본 클래스에서 설명할 수 있는 일반 조건에 도달하면 판매를 금지하거나 포지션을 강제로 닫을 수 있습니다.
경우에 따라 전략에는 판매 및 구매 모두에 대한 일반 데이터가 포함되며, 이는 새 바 도착과 같은 이벤트가 발생할 때 다시 계산되어야 합니다. 이러한 경우 전략이 이벤트에 대한 처리 방법을 구독하는 것이 가능합니다. 위치를 열 수는 없지만 다양한 계산을 할 수 있습니다.
흥미로운 점은 열린 위치로 작업하는 방식이기도 합니다. 기본 클래스는 롱 포지션과 숏 포지션의 별도 목록을 유지합니다. 새 이벤트(예: OnTick)가 발생하면 클래스는 모든 열린 위치 목록을 반복하기 시작하고 SupportBuy SupportSell 메서드를 사용하여 이러한 각 위치를 차례로 처리하도록 제안합니다. 이러한 메서드는 기본 클래스가 현재 제공하는 위치만 닫을 수 있습니다. 다른 모든 위치는 읽기 전용입니다. 따라서 기본 클래스는 현재 순간에 하나의 단일 위치에만 집중할 필요가 있다는 생각을 자손에게 부과합니다. 이 아이디어를 테스트했을 때 가장 복잡한 Expert Advisor의 논리도 훨씬 간단해졌습니다. 또한 다음과 같이 헤지 개념을 자동으로 지원합니다. EA는 롱 포지션과 숏 포지션에 대한 정보를 보관합니다.
TheXpert : ... 트레이딩 부분의 구현은 전략에 따라 다르므로 가상 전략에 대한 공격의 일부로 논의할 내용이 없습니다. 전략의 구현은 이상하게도 전략에 따라 다릅니다. :)
MetaDriver : ... 그러나 반드시 그런 것은 아닙니다. 그것은 거의 나에게 중요하지 않습니다. 전체 거래 부분은 주문, 위치 추적, 견적 및 거래와 관련된 기타 쓰레기를 완전히 구현하는 클래스(CMarketDriver)로 작성됩니다. 모든 악기를 한 번에. 그리고 전략적 부분은 그에게 도구에 대한 권장 시장 위치를 입력으로만 제공합니다. {string Instrument; 형식의 구조 배열을 채웁니다. double Position} 및 MD.Synhronize(PositionArray) 서버와의 동기화를 요청합니다. 그리고 pse. 지금까지는 시장가 주문만 거래 했지만 스프레드 내에서 지정가 주문을 거래하는 버전이 개발 중입니다 (거래 비용 절감). 나는 거래를 위해 이익실현/정지 손실을 사용하지 않지만, MarketDriver는 서버와의 장기간 연결이 끊긴 경우 보호 정지를 설정할 수 있습니다(정지 매개변수는 드라이버 설정에서 한 번 지정됨). 그건 그렇고, 매우 성공적이고 거의 문제가 없는 구조적 솔루션입니다. 테스터에서 전략적 아이디어를 테스트하기 위해 일반적으로 노래 - 거래에 문제가 없으며 모든 관심을 전략에 집중할 수 있습니다. 모든 거래는 오랫동안 디버깅되고 거래 드라이버에 캡슐화되었습니다.
실행을 지정가 주문에 대한 전략으로 철저히 번역하기 시작하자마자 다음과 같은 많은 질문이 즉시 나타납니다.
당신의 전략적 부분(분석가/예측가/뇌)에 속하는 가격에 대한 당신의 한계의 영향.
다중 통화 전략을 위한 동기화
추세와 거래할 때 장기간 실행 부족(트롤? 그렇다면 어떻게, 시장에 침)
부분 실행
...
그런 다음 "실행기"와 "분석기" 사이에 피드백을 도입해야 하며, 또한 어떻게든 이 비이상적인 실행의 매개변수를 분석기의 수학적 모델에 포함시켜야 합니다.
MetaDriver : ... 일반적으로 테스터에서 전략적 아이디어를 테스트하려면 노래 - 거래에 문제가 없습니다 ...
주요 디자인 모델을 배치할 것을 제안합니다.
1. 기능성
2. 목적
3. 이벤트
...
추가하다
4. 구성품
--
일반적으로 모든 프로그램(계획된 프로그램 포함)은 다른 각도에서 볼 수 있습니다. // 이것은 분명합니다.
프로젝트의 초기 분석 동안 나는 반드시 적어도 4가지 측면을 고려하려고 노력합니다.
1. 구조적: 프로그램 코드 및 프로그램 구성요소의 물리적 및 논리적 구성.
2. 기능적(개발 시 기능적 접근 방식과 혼동하지 말 것): 프로그램이 해결하는 작업(제품이 생성하는 제품), 용도, 출력해야 하는 것 등
3. 의사소통: 프로그램에는 어떤 종류의 사용자 인터페이스가 있어야 하며, 어떤 프로그램과 어떻게 데이터 를 교환하고 프로토콜을 교환하는지 등...
4. 관리: 프로그램 관리 방법, 필요한 설정, 자유도 등
모든 측면은 불가분의 관계에 있지만 이러한 다양한 각도(+ 일부 더)를 살펴보면 중요한 미묘함을 놓치지 않고 초기 단계에서 광범위한 결과와 함께 중요한 것을 놓치지 않을 수 있습니다...)
... 일반적으로 모든 프로그램(계획된 프로그램 포함)은 다른 각도에서 볼 수 있습니다. // 이건 분명하다...
절대적으로 동의합니다. 이것은 일반적인 철학적 원칙입니다-다른 관점에서 현상 연구 ...
그리고 개발 초기에는 "프로그램은 무엇을 해야 하고 무엇을 해서는 안 되는가?"라는 질문에 답하려고 노력합니다. 질문의 첫 번째 부분은 시스템 프레임워크(여기서는 MTS)에 속하고 두 번째 부분은 해당되지 않으며 외부에 있습니다.
IMHO, 디자인 모델에 관계없이 모델 요소의 계층 구조를 갖는 것은 매우 중요합니다. 그런 다음 모델을 주요 블록과 구성 블록으로 나누면 연역적 방법이 "일반적인 것에서 특수한 것으로" 잘 작동합니다.
생각의 교환/상호 학습을 위해, 나는 다소 실용적인 문제처럼 보이는 (손가락에서 빨아) 전체 집단 농장과 그것을 구성하는 것을 제안합니다.
예를 들어, 최소한 그러한 작업에 대한 기본 구조(더 정확하게는 이러한 구조의 변형)에 대한 개요를 작성하십시오.
어쨌든 서면 고문이 있습니다(예: 거래 아이디어를 테스트하기 위해). 테스터(고객)의 아이디어가 유망한 결과를 보였다고 가정합니다. 이제 어드바이저를 개발에 편리한 형태로 가져오려면 어드바이저를 다시 작성해야 합니다. 특히 그래픽 사용자 제어판을 제공합니다 .
테스터에서 최적화를 위해 패널을 비활성화하거나 Expert Advisor의 전체 "비그래픽" 구현을 그래픽 인터페이스에 연결할 수 있는 포함된 파일(.mqh)로 이동하는 것이 바람직합니다. "테스트" 및 " 그래픽" 버전 작동의 차이점 없이 (제외하기 위해).
그러한 프로젝트를 구성하는 데 대한 고려 사항을 듣고 읽고 싶습니다. 특히, 그러한 프로젝트에서 이벤트 관리 모델의 구현에 대해. 이중 구현(테스트 + 패널)이 고객의 엄격한 요구 사항이라고 가정합니다(즉, 어떤 방식으로든 수행해야 하며 구현 방법만 선택할 수 있음).
퍼즐을 풀어볼까요?
전문가의 제어판과 전문가 자체가 같은 프로그램의 완전히 다른 두 모듈이라는 것은 자명하다고 생각합니다. 따라서 이러한 각 부분이 서로 독립적인 방식으로 이들을 분리해야 합니다. 즉, Expert Advisor의 일부를 변경할 때(예: 주문 논리 변경) 패널의 논리를 변경할 필요가 없었으며 그 반대의 경우도 마찬가지입니다(패널의 인터페이스를 변경했습니다. Expert Advisor의 논리를 변경할 필요 없음). 가장 먼저 떠오르는 것은 패널과 전문가가 데이터를 교환 할 수 있는 통합 인터페이스의 생성이다. 그러나 불행히도 MQL5의 작성자는 수평 링크 생성 가능성을 제공하지 않았습니다. 즉, MQL5 도구를 사용하여 둘 사이의 인터페이스를 설명하는 것이 불가능합니다. 그런 다음 수직 통합의 경로가 있습니다. Expert Advisor는 패널과 상호 작용하기에 충분한 메서드와 데이터를 포함하는 기본 클래스에서 상속되어야 합니다. 이는 기본 조언에서 상속된 모든 Expert Advisor도 패널을 표시하고 상호 작용할 수 있는 기능을 획득함을 의미합니다. 동시에 패널과의 상호작용을 담당하는 메소드의 구현은 자손에게 위임되어서는 안 되며, 기본 클래스의 뒤에서 수행되어야 합니다. "후손! 패널로 작업하려면 매개변수를 사용하여 내 메서드를 호출하세요."라는 메시지가 전혀 작동하지 않습니다. 이상적으로는 기본 클래스에서 상속된 파생된 Expert Advisor가 편리한 방식으로 거래되어야 하며 해당 작업이 이 패널에 자동으로 표시됩니다.
보편적인 기본 거래 클래스를 구성하는 방법은 별개의 흥미로운 주제입니다. 이 문제에 대한 몇 년 간의 연습은 마침내 저를 개인적으로 보편적인 계획으로 이끌었습니다. 그것은 투명하고 보편적인 것으로 밝혀졌습니다. 관심이 있으시면 그녀에게 기본 순서도를 줄 수 있습니다(하하, 순서도를 그리는 것은 여전히 유용한 연습입니다). 그러나 어쨌든 모든 사람은 자신의 방식을 가지고 있으며 한 사람에게 좋은 해결책이 다른 사람에게 좋은 해결책이 될 수는 없습니다.
관심이 있으시면 그녀에게 기본 순서도를 줄 수 있습니다(하하, 결국 순서도를 그리는 것은 유용한 연습입니다).
1. 가장 먼저 떠오르는 것은 패널과 전문가가 데이터를 교환할 수 있는 통일된 인터페이스의 생성이다.
2. 불행히도 MQL5의 작성자는 수평 링크 생성 가능성을 제공하지 않았습니다. 즉, MQL5 도구를 사용하여 둘 사이의 인터페이스를 설명하는 것이 불가능합니다.
1. 확실히.
2. 글쎄, 왜 안되지? 맞춤 이벤트는 어떻습니까? 상당히 수평적이고 보편적입니다.
3. 그 다음은 수직적 통합의 길입니다. Expert Advisor는 패널과 상호 작용하기에 충분한 메서드와 데이터를 포함하는 기본 클래스에서 상속되어야 합니다. 이는 기본 조언에서 상속된 모든 Expert Advisor도 패널을 표시하고 상호 작용할 수 있는 기능을 획득함을 의미합니다. 동시에 패널과의 상호작용을 담당하는 메소드의 구현은 자손에게 위임되어서는 안 되며, 기본 클래스의 뒤에서 수행되어야 합니다. "후손! 패널로 작업하려면 매개변수를 사용하여 내 메서드를 호출하세요."라는 메시지가 전혀 작동하지 않습니다. 이상적으로는 기본 클래스에서 상속된 파생된 Expert Advisor가 편리한 방식으로 거래되어야 하며 해당 작업이 이 패널에 자동으로 표시됩니다.
3. 2항에 동의하지 않기 때문에 이 옵션은 아직 파지 않습니다.
--
내가 아주 좋아하는 옵션이 있습니다. ("전환 가능한" 패널이 있는 옵션). 패널을 표시기처럼 보이게 합니다. 전문가가 테스터에 있으면 패널을 로드하지 않습니다. 추가 보너스는 패널이 다른 스레드에서 실행되어 전문가에게 더 많은 리소스를 제공한다는 것입니다.
패널의 다양성에 관해서. 패널이 ini-file을 사용하여 완전히 구성되었다는 사실에 대한 근본적인 장애물은 보이지 않습니다. 저것들. 거기에서 사용자와 상호 작용할 때 생성해야 하는 제한된 고정 시각적 구성 요소 + 이벤트 코드 집합에서 패널을 만드는 데 필요한 모든 데이터를 절대적으로 작성할 수 있습니다.
보편적인 기본 거래 클래스를 구성하는 방법은 별개의 흥미로운 주제입니다. 이 문제에 대한 몇 년 간의 연습은 마침내 저를 개인적으로 보편적인 계획으로 이끌었습니다. 그것은 투명하고 보편적인 것으로 밝혀졌습니다. 관심이 있다면 그녀에게 개략적인 블록 다이어그램을 줄 수 있습니다. ....
1. 확실히.
왜 ? 과도한 일반화는 조기 최적화만큼 나쁩니다.
그리고 이벤트를 통해 같은 모듈의 블록을 연결하는 것은 ... 느리고 불편합니다.
할 수 있습니다. 나는 심지어 매우 관심이 있습니다. 예, 실질적으로 유용할 수 있습니다.
파란색 프레임 - 기본 클래스 엔터티. 파생 클래스 엔터티의 빨간색 테두리입니다. 기본 클래스가 네 가지 메서드로 논리 정의를 자식에게 부과한다는 것을 알 수 있습니다. 모든 전략에 대한 설명을 단 4가지 상황에 대한 설명으로 줄이는 것은 이 방법입니다.
1. 롱포지션을 열기 위한 모든 규칙이 충족되면 InitBuy() 메서드에서 롱포지션이 열립니다.
2. 롱 포지션 청산에 대한 모든 규칙이 충족되면 SupportBuy() 메소드에서 롱 포지션이 청산됩니다.
3. 매도 포지션 개설에 대한 모든 규칙이 충족되면 InitSell() 메서드에서 매도 포지션이 열립니다.
4. 숏 포지션 청산에 대한 모든 규칙이 충족되면 SupportSell() 메서드에서 숏 포지션이 청산됩니다.
이 논리에 따르면 전략의 반전은 하나의 방법(예: 매수 매도, 매도 매도)이 아니라 서로 독립적인 두 가지 방식으로 설명됩니다. 이 접근 방식은 매우 편리하기 때문에 밝혀졌습니다. 예를 들어 클릭 한 번으로 기본 클래스에서 설명할 수 있는 일반 조건에 도달하면 판매를 금지하거나 포지션을 강제로 닫을 수 있습니다.
경우에 따라 전략에는 판매 및 구매 모두에 대한 일반 데이터가 포함되며, 이는 새 바 도착과 같은 이벤트가 발생할 때 다시 계산되어야 합니다. 이러한 경우 전략이 이벤트에 대한 처리 방법을 구독하는 것이 가능합니다. 위치를 열 수는 없지만 다양한 계산을 할 수 있습니다.
흥미로운 점은 열린 위치로 작업하는 방식이기도 합니다. 기본 클래스는 롱 포지션과 숏 포지션의 별도 목록을 유지합니다. 새 이벤트(예: OnTick)가 발생하면 클래스는 모든 열린 위치 목록을 반복하기 시작하고 SupportBuy SupportSell 메서드를 사용하여 이러한 각 위치를 차례로 처리하도록 제안합니다. 이러한 메서드는 기본 클래스가 현재 제공하는 위치만 닫을 수 있습니다. 다른 모든 위치는 읽기 전용입니다. 따라서 기본 클래스는 현재 순간에 하나의 단일 위치에만 집중할 필요가 있다는 생각을 자손에게 부과합니다. 이 아이디어를 테스트했을 때 가장 복잡한 Expert Advisor의 논리도 훨씬 간단해졌습니다. 또한 다음과 같이 헤지 개념을 자동으로 지원합니다. EA는 롱 포지션과 숏 포지션에 대한 정보를 보관합니다.실행을 지정가 주문에 대한 전략으로 철저히 번역하기 시작하자마자 다음과 같은 많은 질문이 즉시 나타납니다.
그런 다음 "실행기"와 "분석기" 사이에 피드백을 도입해야 하며, 또한 어떻게든 이 비이상적인 실행의 매개변수를 분석기의 수학적 모델에 포함시켜야 합니다.
MetaDriver : ... 일반적으로 테스터에서 전략적 아이디어를 테스트하려면 노래 - 거래에 문제가 없습니다 ...
지정가 주문을 위한 전략으로 실행을 철저히 번역하기 시작하는 방법