주제가 잘못되었습니다. 당신은 최적화에 집중하고 있으며, 분명히 요점은 조언자에 있습니다( 매개변수 전달 등). 잠시 동안 최적화를 잊고, 주석 및 인쇄 어드바이저에 충실하고, 시각적 개체에서 다른 매개변수로 운전하고, 중간 데이터를 제어하고, 모든 오류를 찾은 다음 최적화로 돌아갑니다.
동일한 결과는 최적화된 매개변수가 거래 신호의 형성에 영향을 미치지 않는다는 것을 나타내며, 이는 테스터가 아니라 Expert Advisor의 문제입니다.
다음과 같이 매개변수를 설정하면 (iCustom(NULL, 0, "ART", MA_Period, KFK, 0, 1), Digits); -위의 예를 든 것처럼 모든 0을 얻습니다.
iCustom(NULL, 0, "ART", 0, 1), Digits)를 설정하면; - 그런 다음 계산 된 값이 나타납니다.
테스터에서 다른 매개 변수로 실행할 때 트랜잭션 결과가 매우 다르지만 모두 동일합니다.
Angela님, 최적화가 작동하려면 알고리즘에서 옵티마이저가 변경한 값을 어떻게든 사용해야 하며, 특히 이를 지표에 전달해야 합니다. 최적화를 원하는 경우 지표에 매개변수를 전달해야 합니다. 매개변수 없이 표시기를 호출하면(즉, 두 번째 옵션인 iCustom(NULL, 0, "ART", 0, 1)) 실제로 매개변수를 생략하고 표시기는 ART 내부에 작성된 기본 매개변수로 작동합니다(물론 , 최적화되지 않은 경우). 매개변수가 있는 전체 호출 - 첫 번째 옵션은 최적화에 필요한 것입니다. 대부분의 경우 문제는 매개변수를 잘못 전달하는 것입니다. 예를 들어 표시기의 숫자가 더 적고 추가 값을 전달하거나 모든 매개변수를 추가하지 않으면 그 반대의 경우입니다. 표시기가 비밀이면 최소한 매개변수 목록을 제공하십시오.
축하합니다. 나는 또한 꼼꼼함에 익숙해질 때까지 매개변수를 전달하는 데 어려움을 겪었던 것을 기억합니다. 이제 모든 externs와 함께 표시기 코드의 일부를 Expert Advisor에 복사하여 붙여넣고 샘플을 보고 iCustom 을 작성합니다. 바보 같지만 그 이후로는 오류가 없습니다.
그리고 더. 나는 komposter 의 시각적인 iCustom 쓰기 스타일을 관찰했습니다. 모든 것이 당신의 손바닥 안에 있습니다.
/*
Входные параметры индикатора
extern int FastEMA=12;
extern int SlowEMA=26;
extern int SignalSMA=9;
*/double signal =iCustom(Symbol(),Period(),"MACD",
FastEMA ,//параметр 1
SlowEMA ,//параметр 2
SignalSMA ,//параметр 30,//номер буфера индикатора
SignalBar );//бар, с которого получаем данные (внешняя переменная)
TS의 두 번째 버전을 디버깅 중입니다. 첫 번째 버전과 비교하여 트랜잭션 수가 증가하고 최적화된 매개변수의 수가 크게 감소했지만 손실은 두 배로 늘었습니다.
그러나 막연한 의심이 나를 갉아 먹습니다. 시스템은 최적화되고 최적화가 시작될 때까지 매달 매우 안정적으로 작동하지 않지만 GA를 사용한 결과는 이틀 만에 나타납니다. 낙관론을 불러일으키지 마십시오. 6월 기록에 대한 최적화 결과는 같은 기간에 초기 매개변수로 테스트할 때보다 나쁩니다. 6월, 7월, 8월에 3개 주를 주는데 Buy만 디버깅 중인데 안정적인 결과를 위해 최적화를 통해 그런 시스템을 꺼낼 수 있습니까, 아니면 즉시 새 개발을 시작해야 하나요?
mql-code만 EA에 포함되어 있는 경우 시작 가격을 기반으로 하는 모델을 사용하면 800 실행이 그렇게 느려지지 않아야 하기 때문에 무언가가 분명히 코딩되지 않은 것입니다. 아니면 제가 뭔가를 오해하고 있는 걸까요? 신경망 라이브러리 등과 같은 외부 바인딩을 가진 전문가는 일반적으로 매우 사려깊습니다. 물론 많은 중첩 루프(또는 일부 "대식" 표시기의 호출)가 mql로 작성되었다고 가정할 수도 있습니다. 그러면 완전히 느려질 수 있습니다. . 이와 관련하여 리팩토링이 필요하다는 생각만 반복할 수 있습니다. ;-) - 코드 조각 또는 전체 코드를 다시 확인하고 다시 작성합니다.
marketeer писал(а)>> mql-code만 EA에 포함되어 있는 경우 시작 가격을 기반으로 하는 모델을 사용하면 800 실행이 그렇게 느려지지 않아야 하기 때문에 무언가가 분명히 코딩되지 않은 것입니다. 아니면 제가 뭔가를 오해하고 있는 걸까요? 신경망 라이브러리 등과 같은 외부 바인딩을 가진 전문가는 일반적으로 매우 사려깊습니다. 물론 많은 중첩 루프(또는 일부 "대식" 표시기의 호출)가 mql로 작성되었다고 가정할 수도 있습니다. 그러면 완전히 느려질 수 있습니다. . 이와 관련하여 리팩토링이 필요하다는 생각만 반복할 수 있습니다. ;-) - 코드 조각 또는 전체 코드를 다시 확인하고 다시 작성합니다.
8000회가 넘는 런 중 800회가 글을 쓰는 시점에 5시간의 최적화와 함께 지나갔고 아직 2일의 시간이 남았다. 그러나 나는 끝을 기다리지 않고 일부 매개변수의 열거 범위를 줄이고 다시 시작하여 8시간 만에 전체 최적화를 완료했습니다.
즉, iCustom 이 변경되는 이 라인만? 그런 다음이 지표를 자세히 고려할 필요가 있습니다.
주제가 잘못되었습니다. 당신은 최적화에 집중하고 있으며, 분명히 요점은 조언자에 있습니다( 매개변수 전달 등). 잠시 동안 최적화를 잊고, 주석 및 인쇄 어드바이저에 충실하고, 시각적 개체에서 다른 매개변수로 운전하고, 중간 데이터를 제어하고, 모든 오류를 찾은 다음 최적화로 돌아갑니다.
동일한 결과는 최적화된 매개변수가 거래 신호의 형성에 영향을 미치지 않는다는 것을 나타내며, 이는 테스터가 아니라 Expert Advisor의 문제입니다.
다음과 같이 매개변수를 설정하면 (iCustom(NULL, 0, "ART", MA_Period, KFK, 0, 1), Digits); -위의 예를 든 것처럼 모든 0을 얻습니다.
iCustom(NULL, 0, "ART", 0, 1), Digits)를 설정하면; - 그런 다음 계산 된 값이 나타납니다.
테스터에서 다른 매개 변수로 실행할 때 트랜잭션 결과가 매우 다르지만 모두 동일합니다.
Angela님, 최적화가 작동하려면 알고리즘에서 옵티마이저가 변경한 값을 어떻게든 사용해야 하며, 특히 이를 지표에 전달해야 합니다. 최적화를 원하는 경우 지표에 매개변수를 전달해야 합니다. 매개변수 없이 표시기를 호출하면(즉, 두 번째 옵션인 iCustom(NULL, 0, "ART", 0, 1)) 실제로 매개변수를 생략하고 표시기는 ART 내부에 작성된 기본 매개변수로 작동합니다(물론 , 최적화되지 않은 경우). 매개변수가 있는 전체 호출 - 첫 번째 옵션은 최적화에 필요한 것입니다. 대부분의 경우 문제는 매개변수를 잘못 전달하는 것입니다. 예를 들어 표시기의 숫자가 더 적고 추가 값을 전달하거나 모든 매개변수를 추가하지 않으면 그 반대의 경우입니다. 표시기가 비밀이면 최소한 매개변수 목록을 제공하십시오.
모두 덕분에 이유를 알았습니다.지표에서 Expert Advisor로 전달되는 매개 변수 선언 순서가 일치하지 않았습니다.
고문은 가지고 있었다
extern int MA_Period=151; // 101 10 201
외부 이중 KFK=0.9; // 0.7 0.005 1.
표시기에서 반대의 경우도 마찬가지입니다.
외부 이중 KFK=0.9; // 0.7 0.005 1.
extern int MA_Period=151; // 101 10 201
이 때문에 모든 것이 시각화 모드에서 작동했지만 최적화 모드에서는 작동 하지 않았습니다.
축하합니다. 나는 또한 꼼꼼함에 익숙해질 때까지 매개변수를 전달하는 데 어려움을 겪었던 것을 기억합니다. 이제 모든 externs와 함께 표시기 코드의 일부를 Expert Advisor에 복사하여 붙여넣고 샘플을 보고 iCustom 을 작성합니다. 바보 같지만 그 이후로는 오류가 없습니다.
그리고 더. 나는 komposter 의 시각적인 iCustom 쓰기 스타일을 관찰했습니다. 모든 것이 당신의 손바닥 안에 있습니다.
TS의 두 번째 버전을 디버깅 중입니다. 첫 번째 버전과 비교하여 트랜잭션 수가 증가하고 최적화된 매개변수의 수가 크게 감소했지만 손실은 두 배로 늘었습니다.
그러나 막연한 의심이 나를 갉아 먹습니다. 시스템은 최적화되고 최적화가 시작될 때까지 매달 매우 안정적으로 작동하지 않지만 GA를 사용한 결과는 이틀 만에 나타납니다. 낙관론을 불러일으키지 마십시오. 6월 기록에 대한 최적화 결과는 같은 기간에 초기 매개변수로 테스트할 때보다 나쁩니다. 6월, 7월, 8월에 3개 주를 주는데 Buy만 디버깅 중인데 안정적인 결과를 위해 최적화를 통해 그런 시스템을 꺼낼 수 있습니까, 아니면 즉시 새 개발을 시작해야 하나요?
mql-code만 EA에 포함되어 있는 경우 시작 가격을 기반으로 하는 모델을 사용하면 800 실행이 그렇게 느려지지 않아야 하기 때문에 무언가가 분명히 코딩되지 않은 것입니다. 아니면 제가 뭔가를 오해하고 있는 걸까요? 신경망 라이브러리 등과 같은 외부 바인딩을 가진 전문가는 일반적으로 매우 사려깊습니다. 물론 많은 중첩 루프(또는 일부 "대식" 표시기의 호출)가 mql로 작성되었다고 가정할 수도 있습니다. 그러면 완전히 느려질 수 있습니다. . 이와 관련하여 리팩토링이 필요하다는 생각만 반복할 수 있습니다. ;-) - 코드 조각 또는 전체 코드를 다시 확인하고 다시 작성합니다.
8000회가 넘는 런 중 800회가 글을 쓰는 시점에 5시간의 최적화와 함께 지나갔고 아직 2일의 시간이 남았다. 그러나 나는 끝을 기다리지 않고 일부 매개변수의 열거 범위를 줄이고 다시 시작하여 8시간 만에 전체 최적화를 완료했습니다.
최상의 결과:
수익성 있는 거래의 수는 무익한 거래의 수를 초과하고 평균 수익성 있는 거래는 손실되는 거래보다 큽니다. 이는 매우 좋은 신호입니다. 제 생각에는 이 시스템을 버려서는 안되며 장기간에 걸쳐 그 행동을 적절하게 연구할 필요가 있습니다. 다른 십자가에 놓을 수도 있습니다.