하지만 저는 항상 Expert Advisor 내부의 기능(또는 OOP 클래스)으로 테스터를 실행하고 싶었습니다. 그러면 지금보다 훨씬 더 효율적으로 테스트/최적화 프로세스를 관리할 수 있을 것입니다. 실제로, 이제는 기록 기간에 따른 순차적 테스트도 프로그래밍 방식이 아닌 탭에서 수행됩니다. 일부 테스트/최적화 프로그램을 만든 다음 오프라인(예: 야간)에서 테스터를 실행하는 것이 편리할 것입니다. 작은 DBMS 내에서 이것을 하는 것이 좋을 것입니다.
네 가지 의 경우 자동 최적화가 프로그래밍 방식으로 실행됩니다. 장인이 5개로 할 것 같아요. 유일한 질문은 MT5의 출시 시간입니다.
하지만 저는 항상 Expert Advisor 내부의 기능(또는 OOP 클래스)으로 테스터를 실행하고 싶었습니다. 그러면 지금보다 훨씬 더 효율적으로 테스트/최적화 프로세스를 관리할 수 있을 것입니다. 실제로, 이제는 기록 기간에 따른 순차적 테스트도 프로그래밍 방식이 아닌 탭에서 수행됩니다. 일부 테스트/최적화 프로그램을 만든 다음 오프라인(예: 야간)에서 테스터를 실행하는 것이 편리할 것입니다. 작은 DBMS 내에서 이것을 하는 것이 좋을 것입니다.
전문가에게 테스트를 하기에는 문제가 없다고 봅니다. 또 다른 질문은 이것을 구현하는 가장 좋은 방법은 무엇입니까?
Expert Advisor 내에서 OOP의 도움으로도 가능합니다(모든 것이 MQL 자체에서 구성되는 것이 편리합니다). 예를 들어 저에게는 이 접근 방식이 흥미로웠습니다.
외부 소프트웨어에서 처리를 실행하고 거기에서 결과를 선택할 수 있습니다(많은 이점이 있음).
예, 하지만 탭 대신 별도의 창(현재)이 있어 훨씬 더 편리했습니다. 그리고 최적화 중에도 시각화 모드에서 병렬 테스트가 있었다면 그것은 동화가 될 것입니다 ...
편의성에 대한 두 번째 질문입니다.
누군가는 25''의 세 대의 모니터를 가지고 있습니다. 물론 그는 모든 탭을 개별적으로 분산시킬 수 있습니다.
그러나 대다수의 인구를 잊지 마십시오. 하나의 모니터. 그리고 우리는 조심스럽게 모든 영역을 저장해야 합니다.
하지만 저는 항상 Expert Advisor 내부의 기능(또는 OOP 클래스)으로 테스터를 실행하고 싶었습니다. 그러면 지금보다 훨씬 더 효율적으로 테스트/최적화 프로세스를 관리할 수 있을 것입니다. 실제로, 이제는 기록 기간에 따른 순차적 테스트도 프로그래밍 방식이 아닌 탭에서 수행됩니다. 일부 테스트/최적화 프로그램을 만든 다음 오프라인(예: 야간)에서 테스터를 실행하는 것이 편리할 것입니다. 작은 DBMS 내에서 이것을 하는 것이 좋을 것입니다.
하지만 저는 항상 Expert Advisor 내부의 기능(또는 OOP 클래스)으로 테스터를 실행하고 싶었습니다. 그러면 지금보다 훨씬 더 효율적으로 테스트/최적화 프로세스를 관리할 수 있을 것입니다. 실제로, 이제는 기록 기간에 따른 순차적 테스트도 프로그래밍 방식이 아닌 탭에서 수행됩니다. 일부 테스트/최적화 프로그램을 만든 다음 오프라인(예: 야간)에서 테스터를 실행하는 것이 편리할 것입니다. 작은 DBMS 내에서 이것을 하는 것이 좋을 것입니다.
전문가에게 테스트를 하기에는 문제가 없다고 봅니다. 또 다른 질문은 이것을 구현하는 가장 좋은 방법은 무엇입니까?
Expert Advisor 내에서 OOP의 도움으로도 가능합니다(모든 것이 MQL 자체에서 구성되는 것이 편리합니다). 예를 들어 저에게는 이 접근 방식이 흥미로웠습니다.
외부 소프트웨어에서 처리를 실행하고 거기에서 결과를 선택할 수 있습니다(많은 이점이 있음).
필요한 경우 DBMS를 사용할 수도 있습니다.
전문가에게 테스트를 하기에는 문제가 없다고 봅니다.
흥미로운 주제. 이에 대한 기사가 있었습니까? 지금까지는 이것이 어떻게 구현될 수 있는지 전혀 모릅니다.
적어도 MQL5에는 기사가 없는 것 같았습니다(틀릴 수 있지만). 주제는 가상 거래 및 자동 최적화와 교차합니다(이러한 주제에 대한 기사는 충분한 수로 존재하는 것 같습니다).
지난 주 데이터에 대한 가상 거래의 관점에서 이 문제에 관심이 있었습니다(자동 최적화는 주말에 수행된다는 아이디어였습니다).
순수 MQL5에서의 실행에 대해 생각해 보았지만 다음과 같은 어려움에 봉착했습니다.
1. 여러 캐릭터의 작업을 구현하는 것은 매우 어렵습니다(지금까지 한 쌍만 작업하기로 결정했습니다).
2. 멀티스레딩을 올바르게 구현하는 것은 매우 어렵습니다.
3. 시간이 많이 걸린다. 초기화 과정이나 주말에 제작할 가치가 있습니다.
4. 제 생각에는 입력 매개변수(최적화 - 열거 포함)로 작업하는 것이 매우 어렵습니다. 저는 여전히 TP, SL 및 Lot 매개변수로 작업하는 것에 대해 생각하고 있습니다.
추신
지표로 작업할 때도 특정 어려움이 있었습니다.
여기에서는 외부 소프트웨어에서 작업하는 것이 더 쉬울 것이며(무엇을 어떻게 하든 상관없이) 최적화 결과 를 얻을 수 있습니다.
MT4의 바로 그 모습에서 커서를 십자형으로 전환할 때 막대로의 자화 모드를 보고 싶었습니다. 특히 스케일이 작은 경우 조준하기가 매우 불편합니다.
자화되지 않는 경우 최소한 커서가 위치한 막대를 강조 표시합니다.
막대 사이에는 데이터가 없습니다. 왜 이러한 스윙이 발생합니까? 한 눈으로 데이터 창을 보고 다른 눈으로 커서와 마우스를 따라 약간 움직여야합니다.
물론 과장이겠지만) 마그네틱 커서는 아주 편리한 것인데, 거기에 데이터 창(전환 가능)도 붙이면 완전 예뻐요.
나는 이것을 MT5에서 보고 싶다.
MT4 테스트 때 제안했는데 거절당했는데 이유가 기억나지 않습니다.
MQL5 프로젝트가 MetaEditor 환경에서 dll로 컴파일될 수 있다는 그런 바람이 있었습니다. 작성된 코드를 다시 작성하지 않고 다른 플랫폼으로 이식할 수 있도록 합니다.
이것이 구현될 가능성은 거의 없으며 그 이유는 무엇입니까?
다른 MT5로 전송하는 것은 여전히 가능하지만 DLL이 필요한 경우 어쨌든 완전히 작동하지 않습니다.
Думал на счет выполнения на чистом MQL5, столкнулся с такими трудностями:
이것이 구현될 가능성은 거의 없으며 그 이유는 무엇입니까?
다른 MT5로 전송하는 것은 여전히 가능하지만 DLL이 필요한 경우 어쨌든 완전히 작동하지 않습니다.