테스터의 단일 실행은 문제 없이 실행되지만 매개변수 선택을 전체 열거로 설정하자마자 테스터는 10배에서 10배 느리게 작동하기 시작합니다. 한 번 실행하면 속도가 적절하고 최적화를 수행하면 속도가 눈에 띄게 떨어지는 이유가 명확하지 않습니다. 그리고 기하급수적으로 떨어집니다. 백분율은 처음에는 모든 것이 원래대로 진행되고 있지만 최종 단계에 가까워질수록 속도가 점점 낮아지고 있음을 보여줍니다. 내 코드에서 루핑이나 기타 문제를 찾았지만 찾지 못했습니다. 그 후 위의 코드를 내 알고리즘과 lo 및 보라로 교체했습니다! 이제 최적화가 일반 균일 속도로 실행됩니다. 여기에서 나는 문제가 OnTradeTransaction 함수 본문의 어딘가에 있는 MQL5 내부에 있다고 결론지었습니다. 이에 개발자 여러분의 많은 관심 부탁드립니다.
ps. 전문가의 코드를 퍼뜨리는 것은 불가능합니다. 그것은 나에게 가치가 있습니다. 2000년부터 현재까지의 모든 Expert Advisors에서 위에서 언급한 코드를 사용하고 OHLC M5의 최적화 속도를 살펴보십시오.
테스터의 단일 실행은 문제 없이 실행되지만 매개변수 선택을 전체 열거로 설정하자마자 테스터는 10배에서 10배 느리게 작동하기 시작합니다. 한 번 실행하면 속도가 적절하고 최적화를 수행하면 속도가 눈에 띄게 떨어지는 이유가 명확하지 않습니다. 그리고 기하급수적으로 떨어집니다. 백분율은 처음에는 모든 것이 원래대로 진행되고 있지만 최종 단계에 가까워질수록 속도가 점점 낮아지고 있음을 보여줍니다. 내 코드에서 루핑이나 기타 문제를 찾았지만 찾지 못했습니다. 그 후 위의 코드를 내 알고리즘과 lo 및 보라로 교체했습니다! 이제 최적화가 일반 균일 속도로 실행됩니다. 여기에서 나는 문제가 OnTradeTransaction 함수 본문의 어딘가에 있는 MQL5 내부에 있다고 결론지었습니다. 이에 개발자 여러분의 많은 관심 부탁드립니다.
ps. 전문가의 코드를 퍼뜨리는 것은 불가능합니다. 그것은 나에게 가치가 있습니다. 2000년부터 현재까지의 모든 Expert Advisors에서 위에서 언급한 코드를 사용하고 OHLC M5의 최적화 속도를 살펴보십시오.
A100 : 저것들. OnTradeTransaction() 사용을 거부했습니까? - 그러면 속도가 증가하는 것이 논리적입니다. - 모든 경우에 호출됩니다.
자연스럽게 거절했다. 어떤 이유로 든 호출 된 것이 분명합니다. 단일 실행으로 속도가 적절하고 최적화로 속도가 급격히 떨어지는 이유가 명확하지 않습니다. 그리고 여기에서 요점은 매개변수 자체에 있는 것이 아니라 다른 동지가 위에서 쓴 것처럼 10번 정도 철저하게 확인했습니다. 여기에서 어디선가 개발자의 실수가 스며들었다는 결론.
호환성을 위해 0으로 설정한 것은 분명하지만 사용하지 않는 enum = WRONG_VALUE 의 올바른 초기화와 함께 올바르게 작동하지 않는 이유는 명확하지 않습니다. 이 접근 방식을 사용하면 이식성이 없고 숨겨진 오류의 가능성이 크게 증가합니다.
이 규칙을 기억하십니까?
규칙 : 명명된 상수 - 열거형의 멤버에 특정 값이 명시적으로 할당되지 않은 경우 해당 값이 자동으로 생성됩니다. 열거형의 첫 번째 멤버인 경우 값 0이 할당되고 모든 후속 멤버의 경우 이전 멤버의 값에 1을 더하여 값이 계산됩니다.
대부분의 경우 요청 필드 작성의 정확성을 확인하는 것은 열거형 멤버의 값이 음수가 될 수 없다는 사실에서 비롯됩니다. 이 경우 열거형의 멤버에 WRONG_VALUE 값을 할당할 가능성은 고려되지 않습니다.
이 경우 열거형의 멤버에 WRONG_VALUE 값을 할당할 가능성은 고려되지 않습니다.
이것이 바로 오류라고 생각합니다. 특정 열거형이 사용되지 않는 경우 - 해당 값이 WRONG_VALUE 인 것이 논리적이며 예를 들어 실제로 = 0인 ORDER_TYPE_BUY가 아닙니다.
가장 중요한 것은 호환성을 유지하면서 OrderCheck() 및 OrderSend()의 논리를 변경하는 것을 방해하는 것은 없습니다.
가장 중요한 것은 호환성을 유지하면서 OrderCheck() 및 OrderSend()의 논리를 변경하는 것을 방해하는 것은 없습니다.
이상한 버그를 발견했습니다.
내 고문에서이 코드를 사용합니다.
테스터의 단일 실행은 문제 없이 실행되지만 매개변수 선택을 전체 열거로 설정하자마자 테스터는 10배에서 10배 느리게 작동하기 시작합니다. 한 번 실행하면 속도가 적절하고 최적화를 수행하면 속도가 눈에 띄게 떨어지는 이유가 명확하지 않습니다. 그리고 기하급수적으로 떨어집니다. 백분율은 처음에는 모든 것이 원래대로 진행되고 있지만 최종 단계에 가까워질수록 속도가 점점 낮아지고 있음을 보여줍니다. 내 코드에서 루핑이나 기타 문제를 찾았지만 찾지 못했습니다. 그 후 위의 코드를 내 알고리즘과 lo 및 보라로 교체했습니다! 이제 최적화가 일반 균일 속도로 실행됩니다. 여기에서 나는 문제가 OnTradeTransaction 함수 본문의 어딘가에 있는 MQL5 내부에 있다고 결론지었습니다. 이에 개발자 여러분의 많은 관심 부탁드립니다.
ps. 전문가의 코드를 퍼뜨리는 것은 불가능합니다. 그것은 나에게 가치가 있습니다. 2000년부터 현재까지의 모든 Expert Advisors에서 위에서 언급한 코드를 사용하고 OHLC M5의 최적화 속도를 살펴보십시오.
이상한 버그를 발견했습니다.
내 고문에서이 코드를 사용합니다.
테스터의 단일 실행은 문제 없이 실행되지만 매개변수 선택을 전체 열거로 설정하자마자 테스터는 10배에서 10배 느리게 작동하기 시작합니다. 한 번 실행하면 속도가 적절하고 최적화를 수행하면 속도가 눈에 띄게 떨어지는 이유가 명확하지 않습니다. 그리고 기하급수적으로 떨어집니다. 백분율은 처음에는 모든 것이 원래대로 진행되고 있지만 최종 단계에 가까워질수록 속도가 점점 낮아지고 있음을 보여줍니다. 내 코드에서 루핑이나 기타 문제를 찾았지만 찾지 못했습니다. 그 후 위의 코드를 내 알고리즘과 lo 및 보라로 교체했습니다! 이제 최적화가 일반 균일 속도로 실행됩니다. 여기에서 나는 문제가 OnTradeTransaction 함수 본문의 어딘가에 있는 MQL5 내부에 있다고 결론지었습니다. 이에 개발자 여러분의 많은 관심 부탁드립니다.
ps. 전문가의 코드를 퍼뜨리는 것은 불가능합니다. 그것은 나에게 가치가 있습니다. 2000년부터 현재까지의 모든 Expert Advisors에서 위에서 언급한 코드를 사용하고 OHLC M5의 최적화 속도를 살펴보십시오.
다른 매개 변수로 전문가는 다른 시간 동안 작업할 수 있습니다.
위의 코드를 내 알고리즘으로 교체한 후
저것들. OnTradeTransaction() 사용을 거부했습니까? - 그러면 속도가 증가하는 것이 논리적입니다. - 모든 경우에 호출됩니다.
그리고 최소한의 테스트 케이스를 만들고 서비스 데스크 구독을 취소하는 데 방해가 되는 것은 무엇입니까?