또한 시장 상황 등을 업데이트하기 위해 사용자 개입 없이 정전 등으로부터 복구할 수 있는 EA를 구축해야 하는 경우 어쨌든 파일 액세스 기능을 구축하는 자신을 발견하게 될 것임을 고려하십시오.
내 경험에 따르면 여러 쌍을 거래하는 EA를 구축하는 데 많은 어려움을 겪을 것입니다.
1.각 쌍에는 고유한 사용자 정의 논리, 최적화가 필요하며 일부 쌍의 경우 다른 거래 전략이 필요할 수도 있습니다. 나는 그것이 잘 거래되는 지점까지 특정 쌍에 최적화된 EA를 썼습니다. 그런 다음 첫 번째 쌍과 가장 상관관계가 높은 다른 쌍에서 사용하려고 했을 때 EA가 작동하고 두 번째 쌍에 최적화되기 위해 많은 것들이 변경되어야 한다는 사실에 놀랐습니다. 각 쌍에는 고유한 사용자 정의 설정, 표시기 값 및 기본 논리 및 전략의 여러 번 변경 사항의 완전한 세트가 필요하다는 것을 알았습니다. 여러 가지 다른 전략과 로직 분기가 내장된 매우 유연한 하나의 EA를 만드는 것이 훨씬 더 합리적입니다. 그런 다음 각 쌍에 대해 최적의 새 .set 파일을 만드는 간단한 문제입니다.
2.만들고자 하는 EA는 전략 테스터에서 백 테스트 및 최적화할 수 없습니다. 내 경험에 따르면 백 테스트 및 최적화가 필수적입니다. Strategy Tester를 사용하지 않았다면 결코 발견할 수 없었던 EA 성능을 크게 향상시킨 최적화가 있습니다. 많은 사람들이 특정 지표에 대해 가장 유용하고 최적의 값으로 간주하는 것에서 너무 멀리 떨어져 있는 지표 설정과 같은 것들을 주었습니다. . EA에 얼마나 많은 매개변수가 있는지 생각해 보십시오. 각 매개변수를 최적화해야 하며 한 매개변수를 최적화할 때마다 다른 매개변수를 변경해야 할 수 있습니다. 그렇기 때문에 각 매개변수를 자체적으로 최적화할 수 없습니다. 최적화의 목표는 모든 매개변수를 최대한 서로 관련하여 최적화하는 것입니다. 테스터를 사용하여 오랜 시간과 많은 작업이 필요할 수 있지만 매개변수를 하나씩 변경하여 수동으로 이러한 최적화를 수행하는 것은 거의 불가능합니다.
다른 참고 사항으로, EA를 코딩하기로 결정한 방식에 관계없이 EA 상태 또는 기타 정보를 파일에 저장하는 것은 대부분의 경우 필수 사항이 아니며 유일한 옵션도 아닙니다. 이를 수행하는 가장 효율적이고 쉬운 방법은 상태를 전역 변수에 저장하는 것입니다. 결국 이것이 MT에 전역 변수 기능이 추가된 바로 그 이유입니다. 또한 여러분 중 일부는 파일 시스템에 저장된 데이터를 교환하여 두 EA 간의 데이터 교환 및 상호 작용을 허용하는 유일한 목적으로 추가 EA를 생성하는 것에 대해 이야기했습니다. 이 또한 불필요합니다. 여러 EA 간의 데이터 교환 및 조건부 논리 기능은 전역 변수의 또 다른 기능입니다.이를 통해 서로 다른 차트에 있는 여러 EA가 모든 EA의 데이터에 액세스하고 해당 데이터를 사용하여 다른 EA의 변경에 영향을 미칠 수 있는 결정을 내릴 수 있습니다. 그 데이터는 컴퓨터 충돌이나 정전이 발생한 경우에도 안전하고 안전합니다. 그러나 EA 간에 데이터를 저장, 읽기 또는 교환하는 과정에서 하나 또는 두 개의 파일이 열려 있을 때 충돌이나 정전이 발생하면 어떻게 됩니까? 데이터 누락, 데이터 손상 및 최악의 0바이트 파일이 발생하거나 파일이 전혀 없을 가능성이 매우 높습니다.전역 변수를 사용하면 이러한 문제가 발생할 수 없습니다. EA 상태는 시스템이 다운되기 전의 밀리초와 정확히 동일합니다. 이제 모두가 이야기하는 GV의 단점은 문자열을 저장할 수 없다는 것입니다.
우선 GV 이름을 문자열 값으로 사용하는 경우 GV는 문자열을 저장할 수 있습니다. 예를 들어 GlobalVariableSet(Symbol() + "LastUptime=" + TimeLocal(), -1);이것의 한 가지 문제는 GV 이름의 길이에 제한이 있으므로 긴 문자열을 저장하는 데 이 방법을 사용할 수 없다는 것입니다. 내가 항상 사용하는 또 다른 훌륭한 해결 방법은 그래픽 개체의 텍스트 필드에 문자열을 저장하는 것입니다. 주문 및 GV로 작업하기만 하면 그들과 함께 작업할 수 있습니다. GV와 그래픽 개체의 총량을 구하는 mql 함수가 있으므로 모든 개체를 반복하고 원하는 것을 찾을 수 있습니다. 다시 한 번 주문을 반복하는 것과 똑같은 방법입니다.
경고- 저는 이제 그래픽 개체가 거래 기능을 향상시킬 수 있는 다른 멋진 방법에 대해 약간의 토끼 길을 가고 있습니다… 주제에서 조금 벗어나지만 유용한 정보가 될 수 있습니다…
그래픽 개체로 할 수 있는 훨씬 더 유용한 작업이 있습니다. 예를 들어, 내 EA 중 하나에 선택적 헤징 기능이 있습니다. 헤징이 활성화되면 새로운 주문에 대한 실제 손절매는 없습니다. 왜냐하면 동일한 기호에 대해 헤지를 할 때 첫 번째 주문이 정상적인 손절매가 될 수 있는 것과 첫 번째 주문이 초과하는 경우 반대 주문을 여는 것이 요점이기 때문입니다. 열려 있어야 합니다. 따라서 귀하의 코드는 손절매가 무엇인지 알고 거래를 모니터링해야 첫 번째 주문이 손절매 가격에 도달할 때 헤지를 열 수 있습니다. 오해가 있는 경우 실제 손절매를 사용할 수 없습니다. 주문에 대한 이유는 주문이 마감되어 헤지 수단이 전혀 없기 때문입니다. 그러나 그래픽 개체를 사용하면 이 작업을 더 잘 수행하고 사용자에게 실제 손절매와 똑같이 보이도록 만들 수 있습니다. 당신이하는 일은 이것입니다 : 당신이 주문할 때 동시에 가격 매개 변수 = 손절매 가격으로 수평선 개체를 만듭니다. 라인 개체의 이름은 "주문 번호" + orderTicket입니다. 설명은 "StopLoss @ " + SLPrice입니다. 선 스타일을 STYLE_DASHDOT으로 설정하고 색상을 빨간색으로 설정하면 실제와 똑같이 보이는 손절매 선이 생깁니다. 작동하도록 하는 코드도 쉽습니다. 필요한 모든 정보 이미 line object에 저장되어 있는 order ticket#과 line object의 값인 SL price 그런 다음 현재 가격이 line에 도달했는지 초과했는지 확인하는 함수를 만듭니다. 라인 이름 필드에 저장된 티켓 번호 그런 다음 동일한 티켓이 있는 미결 주문을 찾습니다. 주문을 선택하여 매수 또는 매도 주문인지 확인하고 로트 크기도 확인합니다. 이제 모든 정보를 얻었습니다. 헤지 주문을 열 필요가 있습니다. 첫 번째 주문과 반대이고 동일한 로트 크기로 새 주문을 엽니다. 마지막 단계는 손절매 라인을 삭제하는 것입니다. 작동하는 것을 볼 때 매우 멋집니다. '헤지(Hedged)' 상태에 가까워지고 있습니다.
또 다른 장점은 주문이 성공할 수 있다고 생각하는 경우 가격이 다시 유리하게 돌아갈 수 있지만 공간이 조금 더 필요한 경우 SL/Hedge 라인을 약간 위로 끕니다. 표준 SL 및 TP 라인으로 그렇게 할 수 있기를 원하지 않습니까? 시장이 실제로 움직일 때 우리가 신속하게 조정할 수 있도록 손절매와 이익 라인을 움직일 수 있다면 그것은 훌륭한 새로운 기능이 될 것입니다. 물론 위의 단계를 사용하여 오늘 EA에서 그렇게 할 수 있으며 한 가지 좋은 이점은 브로커가 귀하의 SL 또는 TP를 절대 볼 수 없다는 것입니다. 단점은 컴퓨터가 꺼지면 서버 측 SL 또는 TP가 없다는 것입니다. 그러나 FapTurbo와 같은 로봇의 경우에도 마찬가지입니다. 그들의 '스텔스' 방법은 주문에 가짜 SL 및 TP 값을 넣고 가격이 가까워지는 마지막 순간에 코드에서 주문을 닫거나 올바른 SL 및 TP 값으로 주문을 수정하는 것입니다.
나는 우리가 여전히 실시간 처리를 하고 있다는 것을 기억하는 것을 선호하기 때문에 통신을 계속 유지하기 위해 while 루프나 wait 함수를 사용하는 것을 잊어버렸습니다!
EURUSD와 같은 쌍에 EA를 연결하면 다른 모든 쌍을 관리하기에 충분한 신호를 제공합니다. 틱은 매우 자주 발생합니다. 그것은 분의 문제가 아니라 초의 문제입니다(2분 동안 루프를 실행하는 것은 나에게 정말 미친 것처럼 들립니다). 1초의 문제가 아니라면 이유를 생각하거나 다른 브로커에게 문의하십시오.
EA를 eurusd에 연결하여 얻을 수 있는 것보다 더 많이 필요한 경우 각 통화에 연결된 별도의 EA 인스턴스를 실행하는 것을 생각하십시오. 미안하지만 나는 "또는 당신의 시스템을 재고하라"고 생각하는 경향이 있습니다.
이번 포스팅이 다소 성급하게 느껴지셨다면 죄송합니다. 내 관점을 공유하고 싶었습니다.
행운을 빕니다.
저는 초보 프로그래머이므로 토론 목적으로 "가정" 시나리오를 고려하십시오.
루프에서 생산적인 것이 없는 무한한 While 루프를 만드는 것은 나쁜 프로그래밍이라는 것을 알고 있습니다. 또는 이것이 EA의 나머지 부분을 실행하는 것을 방해하지만 EA의 본문을 포함하는 무한한 While 루프를 만드는 경우에는 어떻게 될까요? 나는 MQL4 프로그래밍을 충분히 이해하지 못하여 "통신에 손을 떼라"는 의견을 완전히 이해할 수 없습니다. 독립 실행형 스크립트를 통해 거래 주문 을 시작하는 경우 EA가 무한 루프에서 계속 실행되면 통신 문제가 발생합니까?
나는 계속해서 무한 While 루프를 사용하고 독립형 스크립트를 통해 거래 주문을 발행한다는 아이디어를 가지고 놀고 있습니다. 들어오는 EURUSD 틱에 의존하여 EA를 실행하면 약간의 지연이 발생할 수 있기 때문입니다. 예를 들어, 오늘 0700에서 0800 GMT 사이에 가장 긴 대기 시간은 31초였을 것이지만 나중에 뉴욕 세션이 끝날 무렵에는 들어오는 틱에 대해 대기 시간이 최대 2분까지 걸릴 수 있습니다. 아직 아시아 세션이지만 틱 사이에 긴 간격이 있는 것 같습니다.
EA 본체를 무한 루프에 넣으면 거래 중인 모든 통화를 업데이트하는 빈도를 쉽게 제어하고 지연을 희생하지 않을 수 있습니다. 사실, 1초에 50개가 EA를 통과하는 것이 정신을 마비시키는 경우 루프에 100-250밀리초 sleep 문을 넣어 속도를 약간 늦춰야 할 수도 있습니다.
이 그래프는 2009년 4월 29일 EURUSD의 틱 사이의 시간 간격을 보여줍니다. 이 데이터가 나타내는 시간대가 무엇인지 모르겠습니다. 틱 데이터는 Gain Capital에서 다운로드했습니다.
보시다시피 하루 중 틱 간격이 자주 1분을 초과하고 때로는 2분을 초과하는 기간이 있습니다.
그래프 주셔서 감사합니다. 동일한 지연이 발생하지 않도록 하기 위해 다른 통화 중 하나와 일치시키는 것이 좋습니다. (예를 들어 4쌍에 대한 차트를 쉽게 제시할 수 있다면 감사하겠습니다.)
EA를 구축하기 시작했을 때 eurusd에서 1~2분 동안 틱이 없으면 다른 통화에서도 마찬가지라고 방금 언급했습니다. 그 당시에는 단지 위험했거나 내가 만든 나쁜 선택일 수 있지만 이 아이디어를 유지했고 내 EA는 문제 없이 몇 달 동안 실행되고 있습니다. 사실적 경험은 논리의 부족을 보완하고 나는 내 EA를 이렇게 작동하게 했습니다. 문제가 발생했다면 귀하의 솔루션을 이식했을 것입니다. 2 실행 사이에 지연으로 EA를 깨어있게 유지하려는 귀하의 아이디어를 의미합니다. 내가 아는 한 논리적으로 그렇게 해야 합니다. 하지만 브로커가 틱을 생성하는 방법을 모르기 때문에 더 진행하기 어렵습니다.
또한 프로그램 내에서 실행 중인 시스템에 따라 코드를 작성하는 것이 '정상'이거나 '더 나은' 것입니다.
따라서 다중 통화 처리를 허용하면 일반적으로 모든 틱을 제공하는 채널에 EA를 연결할 수 있어야 합니다. 그것은 우리가 어떤 식으로든 처리해야 하는 시스템 논리의 부족입니다.
나는 두 가지 접근 방식이 모두 좋다고 생각한다.
추가하고 싶은 것은 옵션 #2가 오버헤드가 적기 때문에 성능상의 이점이 있다는 것입니다. 분명히 파일 작업보다 빠른 모든 것이 메모리에 있습니다.
옵션 #3의 한 가지 장점은 MT4가 할 수 없는 작업에 파일 데이터를 사용하려는 경우입니다.
또한 시장 상황 등을 업데이트하기 위해 사용자 개입 없이 정전 등으로부터 복구할 수 있는 EA를 구축해야 하는 경우 어쨌든 파일 액세스 기능 을 구축하는 자신을 발견하게 될 것임을 고려하십시오.
또한 시장 상황 등을 업데이트하기 위해 사용자 개입 없이 정전 등으로부터 복구할 수 있는 EA를 구축해야 하는 경우 어쨌든 파일 액세스 기능을 구축하는 자신을 발견하게 될 것임을 고려하십시오.
내 경험에 따르면 여러 쌍을 거래하는 EA를 구축하는 데 많은 어려움을 겪을 것입니다.
1. 각 쌍에는 고유한 사용자 정의 논리, 최적화가 필요하며 일부 쌍의 경우 다른 거래 전략이 필요할 수도 있습니다. 나는 그것이 잘 거래되는 지점까지 특정 쌍에 최적화된 EA를 썼습니다. 그런 다음 첫 번째 쌍과 가장 상관관계가 높은 다른 쌍에서 사용하려고 했을 때 EA가 작동하고 두 번째 쌍에 최적화되기 위해 많은 것들이 변경되어야 한다는 사실에 놀랐습니다. 각 쌍에는 고유한 사용자 정의 설정, 표시기 값 및 기본 논리 및 전략의 여러 번 변경 사항의 완전한 세트가 필요하다는 것을 알았습니다. 여러 가지 다른 전략과 로직 분기가 내장된 매우 유연한 하나의 EA를 만드는 것이 훨씬 더 합리적입니다. 그런 다음 각 쌍에 대해 최적의 새 .set 파일을 만드는 간단한 문제입니다.
2. 만들고자 하는 EA는 전략 테스터에서 백 테스트 및 최적화할 수 없습니다. 내 경험에 따르면 백 테스트 및 최적화가 필수적입니다. Strategy Tester를 사용하지 않았다면 결코 발견할 수 없었던 EA 성능을 크게 향상시킨 최적화가 있습니다. 많은 사람들이 특정 지표에 대해 가장 유용하고 최적의 값으로 간주하는 것에서 너무 멀리 떨어져 있는 지표 설정과 같은 것들을 주었습니다. . EA에 얼마나 많은 매개변수가 있는지 생각해 보십시오. 각 매개변수를 최적화해야 하며 한 매개변수를 최적화할 때마다 다른 매개변수를 변경해야 할 수 있습니다. 그렇기 때문에 각 매개변수를 자체적으로 최적화할 수 없습니다. 최적화의 목표는 모든 매개변수를 최대한 서로 관련하여 최적화하는 것입니다. 테스터를 사용하여 오랜 시간과 많은 작업이 필요할 수 있지만 매개변수를 하나씩 변경하여 수동으로 이러한 최적화를 수행하는 것은 거의 불가능합니다.
다른 참고 사항으로, EA를 코딩하기로 결정한 방식에 관계없이 EA 상태 또는 기타 정보를 파일에 저장하는 것은 대부분의 경우 필수 사항이 아니며 유일한 옵션도 아닙니다. 이를 수행하는 가장 효율적이고 쉬운 방법은 상태를 전역 변수에 저장하는 것입니다. 결국 이것이 MT에 전역 변수 기능이 추가된 바로 그 이유입니다. 또한 여러분 중 일부는 파일 시스템에 저장된 데이터를 교환하여 두 EA 간의 데이터 교환 및 상호 작용을 허용하는 유일한 목적으로 추가 EA를 생성하는 것에 대해 이야기했습니다. 이 또한 불필요합니다. 여러 EA 간의 데이터 교환 및 조건부 논리 기능은 전역 변수의 또 다른 기능입니다. 이를 통해 서로 다른 차트에 있는 여러 EA가 모든 EA의 데이터에 액세스하고 해당 데이터를 사용하여 다른 EA의 변경에 영향을 미칠 수 있는 결정을 내릴 수 있습니다. 그 데이터는 컴퓨터 충돌이나 정전이 발생한 경우에도 안전하고 안전합니다. 그러나 EA 간에 데이터를 저장, 읽기 또는 교환하는 과정에서 하나 또는 두 개의 파일이 열려 있을 때 충돌이나 정전이 발생하면 어떻게 됩니까? 데이터 누락, 데이터 손상 및 최악의 0바이트 파일이 발생하거나 파일이 전혀 없을 가능성이 매우 높습니다. 전역 변수를 사용하면 이러한 문제가 발생할 수 없습니다. EA 상태는 시스템이 다운되기 전의 밀리초와 정확히 동일합니다. 이제 모두가 이야기하는 GV의 단점은 문자열을 저장할 수 없다는 것입니다.
우선 GV 이름을 문자열 값으로 사용하는 경우 GV는 문자열을 저장할 수 있습니다. 예를 들어 GlobalVariableSet(Symbol() + "LastUptime=" + TimeLocal(), -1); 이것의 한 가지 문제는 GV 이름의 길이에 제한이 있으므로 긴 문자열을 저장하는 데 이 방법을 사용할 수 없다는 것입니다. 내가 항상 사용하는 또 다른 훌륭한 해결 방법은 그래픽 개체의 텍스트 필드에 문자열을 저장하는 것입니다. 주문 및 GV로 작업하기만 하면 그들과 함께 작업할 수 있습니다. GV와 그래픽 개체의 총량을 구하는 mql 함수가 있으므로 모든 개체를 반복하고 원하는 것을 찾을 수 있습니다. 다시 한 번 주문을 반복하는 것과 똑같은 방법입니다.
경고- 저는 이제 그래픽 개체가 거래 기능을 향상시킬 수 있는 다른 멋진 방법에 대해 약간의 토끼 길을 가고 있습니다… 주제에서 조금 벗어나지만 유용한 정보가 될 수 있습니다…
그래픽 개체로 할 수 있는 훨씬 더 유용한 작업이 있습니다. 예를 들어, 내 EA 중 하나에 선택적 헤징 기능이 있습니다. 헤징이 활성화되면 새로운 주문에 대한 실제 손절매는 없습니다. 왜냐하면 동일한 기호에 대해 헤지를 할 때 첫 번째 주문이 정상적인 손절매가 될 수 있는 것과 첫 번째 주문이 초과하는 경우 반대 주문을 여는 것이 요점이기 때문입니다. 열려 있어야 합니다. 따라서 귀하의 코드는 손절매가 무엇인지 알고 거래를 모니터링해야 첫 번째 주문이 손절매 가격에 도달할 때 헤지를 열 수 있습니다. 오해가 있는 경우 실제 손절매를 사용할 수 없습니다. 주문에 대한 이유는 주문이 마감되어 헤지 수단이 전혀 없기 때문입니다. 그러나 그래픽 개체를 사용하면 이 작업을 더 잘 수행하고 사용자에게 실제 손절매와 똑같이 보이도록 만들 수 있습니다. 당신이하는 일은 이것입니다 : 당신이 주문할 때 동시에 가격 매개 변수 = 손절매 가격으로 수평선 개체를 만듭니다. 라인 개체의 이름은 "주문 번호" + orderTicket입니다. 설명은 "StopLoss @ " + SLPrice입니다. 선 스타일을 STYLE_DASHDOT으로 설정하고 색상을 빨간색으로 설정하면 실제와 똑같이 보이는 손절매 선이 생깁니다. 작동하도록 하는 코드도 쉽습니다. 필요한 모든 정보 이미 line object에 저장되어 있는 order ticket#과 line object의 값인 SL price 그런 다음 현재 가격이 line에 도달했는지 초과했는지 확인하는 함수를 만듭니다. 라인 이름 필드에 저장된 티켓 번호 그런 다음 동일한 티켓이 있는 미결 주문을 찾습니다. 주문을 선택하여 매수 또는 매도 주문인지 확인하고 로트 크기도 확인합니다. 이제 모든 정보를 얻었습니다. 헤지 주문을 열 필요가 있습니다. 첫 번째 주문과 반대이고 동일한 로트 크기로 새 주문을 엽니다. 마지막 단계는 손절매 라인을 삭제하는 것입니다. 작동하는 것을 볼 때 매우 멋집니다. '헤지(Hedged)' 상태에 가까워지고 있습니다.
또 다른 장점은 주문이 성공할 수 있다고 생각하는 경우 가격이 다시 유리하게 돌아갈 수 있지만 공간이 조금 더 필요한 경우 SL/Hedge 라인을 약간 위로 끕니다. 표준 SL 및 TP 라인으로 그렇게 할 수 있기를 원하지 않습니까? 시장이 실제로 움직일 때 우리가 신속하게 조정할 수 있도록 손절매와 이익 라인을 움직일 수 있다면 그것은 훌륭한 새로운 기능이 될 것입니다. 물론 위의 단계를 사용하여 오늘 EA에서 그렇게 할 수 있으며 한 가지 좋은 이점은 브로커가 귀하의 SL 또는 TP를 절대 볼 수 없다는 것입니다. 단점은 컴퓨터가 꺼지면 서버 측 SL 또는 TP가 없다는 것입니다. 그러나 FapTurbo와 같은 로봇의 경우에도 마찬가지입니다. 그들의 '스텔스' 방법은 주문에 가짜 SL 및 TP 값을 넣고 가격이 가까워지는 마지막 순간에 코드에서 주문을 닫거나 올바른 SL 및 TP 값으로 주문을 수정하는 것입니다.
안녕하세요,
나는 우리가 여전히 실시간 처리를 하고 있다는 것을 기억하는 것을 선호하기 때문에 통신을 계속 유지하기 위해 while 루프나 wait 함수를 사용하는 것을 잊어버렸습니다!
EURUSD와 같은 쌍에 EA를 연결하면 다른 모든 쌍을 관리하기에 충분한 신호를 제공합니다. 틱은 매우 자주 발생합니다. 그것은 분의 문제가 아니라 초의 문제입니다(2분 동안 루프를 실행하는 것은 나에게 정말 미친 것처럼 들립니다). 1초의 문제가 아니라면 이유를 생각하거나 다른 브로커에게 문의하십시오.
EA를 eurusd에 연결하여 얻을 수 있는 것보다 더 많이 필요한 경우 각 통화에 연결된 별도의 EA 인스턴스를 실행하는 것을 생각하십시오. 미안하지만 나는 "또는 당신의 시스템을 재고하라"고 생각하는 경향이 있습니다.
이번 포스팅이 다소 성급하게 느껴지셨다면 죄송합니다. 내 관점을 공유하고 싶었습니다.
행운을 빕니다.
저는 초보 프로그래머이므로 토론 목적으로 "가정" 시나리오를 고려하십시오.
루프에서 생산적인 것이 없는 무한한 While 루프를 만드는 것은 나쁜 프로그래밍이라는 것을 알고 있습니다. 또는 이것이 EA의 나머지 부분을 실행하는 것을 방해하지만 EA의 본문을 포함하는 무한한 While 루프를 만드는 경우에는 어떻게 될까요? 나는 MQL4 프로그래밍을 충분히 이해하지 못하여 "통신에 손을 떼라"는 의견을 완전히 이해할 수 없습니다. 독립 실행형 스크립트를 통해 거래 주문 을 시작하는 경우 EA가 무한 루프에서 계속 실행되면 통신 문제가 발생합니까?
나는 계속해서 무한 While 루프를 사용하고 독립형 스크립트를 통해 거래 주문을 발행한다는 아이디어를 가지고 놀고 있습니다. 들어오는 EURUSD 틱에 의존하여 EA를 실행하면 약간의 지연이 발생할 수 있기 때문입니다. 예를 들어, 오늘 0700에서 0800 GMT 사이에 가장 긴 대기 시간은 31초였을 것이지만 나중에 뉴욕 세션이 끝날 무렵에는 들어오는 틱에 대해 대기 시간이 최대 2분까지 걸릴 수 있습니다. 아직 아시아 세션이지만 틱 사이에 긴 간격이 있는 것 같습니다.
EA 본체를 무한 루프에 넣으면 거래 중인 모든 통화를 업데이트하는 빈도를 쉽게 제어하고 지연을 희생하지 않을 수 있습니다. 사실, 1초에 50개가 EA를 통과하는 것이 정신을 마비시키는 경우 루프에 100-250밀리초 sleep 문을 넣어 속도를 약간 늦춰야 할 수도 있습니다.
모든 피드백에 감사드립니다.
경고- 저는 이제 그래픽 개체가 거래 기능을 향상시킬 수 있는 다른 멋진 방법에 대해 약간의 토끼 길을 가고 있습니다… 주제에서 조금 벗어나지만 유용한 정보가 될 수 있습니다…
멋진!
내 경험에 따르면 여러 쌍을 거래하는 EA를 구축하는 데 많은 어려움을 겪게 될 것입니다.
내가 이미 결정한 몇 가지 -
1. EA당 한 쌍만 가능합니다.
2. 쌍당 하나의 주문만 가능합니다. (나중에 변경될 수 있지만 충분히 숙달될 때까지 이것을 고수할 것입니다.)
황금빛 경험을 공유해 주셔서 대단히 감사합니다.
판카이
이 그래프는 2009년 4월 29일 EURUSD의 틱 사이의 시간 간격을 보여줍니다. 이 데이터가 나타내는 시간대 가 무엇인지 모르겠습니다. 틱 데이터는 Gain Capital에서 다운로드했습니다.
보시다시피 하루 중 틱 간격이 자주 1분을 초과하고 때로는 2분을 초과하는 기간이 있습니다.
그런 다음 각 쌍에 대해 새로운 최적의 .set 파일을 생성하기만 하면 됩니다.
vangrosh: .set 파일 을 어떻게 만들고 사용 합니까? 해당 유형의 파일에 대한 참조를 찾을 수 없습니다.
또한 시장 상황 등을 업데이트하기 위해 사용자 개입 없이 정전 등으로부터 복구할 수 있는 EA를 구축해야 하는 경우 어쨌든 파일 액세스 기능을 구축하는 자신을 발견하게 될 것임을 고려하십시오.
여기를 살펴보십시오: https://book.mql4.com/special/index
복잡한 프로그램의 일반적인 특성
다중 통화 EA를 생성하려는 경우의 방법입니다.
여기를 살펴보십시오: https://book.mql4.com/special/index
복잡한 프로그램의 일반적인 특성
다중 통화 EA를 생성하려는 경우의 방법입니다.
참조해주셔서 감사합니다.
이 그래프는 2009년 4월 29일 EURUSD의 틱 사이의 시간 간격을 보여줍니다. 이 데이터가 나타내는 시간대가 무엇인지 모르겠습니다. 틱 데이터는 Gain Capital에서 다운로드했습니다.
보시다시피 하루 중 틱 간격이 자주 1분을 초과하고 때로는 2분을 초과하는 기간이 있습니다.
그래프 주셔서 감사합니다. 동일한 지연이 발생하지 않도록 하기 위해 다른 통화 중 하나와 일치시키는 것이 좋습니다. (예를 들어 4쌍에 대한 차트를 쉽게 제시할 수 있다면 감사하겠습니다.)
EA를 구축하기 시작했을 때 eurusd에서 1~2분 동안 틱이 없으면 다른 통화에서도 마찬가지라고 방금 언급했습니다. 그 당시에는 단지 위험했거나 내가 만든 나쁜 선택일 수 있지만 이 아이디어를 유지했고 내 EA는 문제 없이 몇 달 동안 실행되고 있습니다. 사실적 경험은 논리의 부족을 보완하고 나는 내 EA를 이렇게 작동하게 했습니다. 문제가 발생했다면 귀하의 솔루션을 이식했을 것입니다. 2 실행 사이에 지연으로 EA를 깨어있게 유지하려는 귀하의 아이디어를 의미합니다. 내가 아는 한 논리적으로 그렇게 해야 합니다. 하지만 브로커가 틱을 생성하는 방법을 모르기 때문에 더 진행하기 어렵습니다.
또한 프로그램 내에서 실행 중인 시스템에 따라 코드를 작성하는 것이 '정상'이거나 '더 나은' 것입니다.
따라서 다중 통화 처리를 허용하면 일반적으로 모든 틱을 제공하는 채널에 EA를 연결할 수 있어야 합니다. 그것은 우리가 어떤 식으로든 처리해야 하는 시스템 논리의 부족입니다.
문안 인사