명확히 해주세요. "이 포인트에 대한 입력 매개변수가 동일합니다"에 대해 이해하지 못했습니다. 내가 옵티마이저의 작업을 이해하는 한, 각 패스는 고유한 입력 매개변수 세트에 해당합니다. 아니면 유전 알고리즘 을 사용할 때 옵티마이저가 고유한 입력 매개변수 집합을 여러 번 처리할 수 있는 상황이 있을 수 있다고 말하고 싶습니까?
... 글쎄요, 정확히 그 내용입니다. 그런 다음 "캐시에서"모든 후속 점은 최적화 결과의 시각적 인식을 왜곡하는 허구에 불과하다는 것이 밝혀졌습니다.
그건 그렇고, requote 모델링을 선택하면 이 캐시를 사용하면 안 되는 것 같습니다. 개발자들은 이에 대해 어떻게 생각합니까?
그리고 또 다른 버그 : 제 유전자 알고리즘 이 10496을 넘어섰을 때 그래프가 잘못 표시되기 시작했습니다. 수직으로 올바르게 확장되었고 더 높은 결과가 발견되었다는 것을 이해할 수 있었지만 수평으로 업데이트되지 않았습니다. 포인트는 이미 그래프의 경계를 넘어 오른쪽 어딘가에 추가된 것처럼 보였습니다.
서비스 데스크에 작성해 주십시오. 또한 단락 2에서 전체 정보가 중요합니다. EA, 터미널 빌드, 최적화 설정...
개발자에게 요청합니다. MT5에 대한 작업이 한창 진행 중이고 여전히 변경 사항이 적용되는 동안 최적화 패스 수를 늘리는 것이 좋습니다.
내가 이해하는 한 많은 문제에 대한 해결책은 약 10,000개 옵션입니다. 어쩌면 조금 더 많거나 약간 적습니다. 하나의 프로세서에서 몇 시간 동안 검색하면 최상의 옵션을 찾을 수 있습니다.
MQL5+OOP+멀티코어 테스트의 보편성은 MT5를 통해 해결할 수 있는 작업(예: 패턴 검색)의 새로운 지평을 볼 수 있게 해줍니다.
그러나 여기에 문제가 있습니다.
귀하의 사이트에 게시된 기사에는 유전 알고리즘 https://www.mql5.com/ru/articles/55 의 예가 포함되어 있습니다. 여기서 100개 막대에서 검색 문제를 해결하는 데 3^100 직접 열거가 필요합니다. LongInt: )보다 약간 더 많고 17,000번의 반복에서 솔루션을 찾았습니다. 유전 알고리즘은 LongInt보다 더 많은 옵션 중에서 솔루션을 찾을 수 있습니다. 그리고 이 제한은 완전히 불합리하고 구식입니다. 글쎄, MT5 작업의 이 마지막 단계에서 하기가 어려울 것이라는 점을 제외하고.
개발자들에게 큰 부탁인데, 그렇게 어렵지 않다면 패스 횟수를 2^LongInt(2의 제곱) 이상으로 해주세요.
예를 들어, 사용자가 인터페이스에서 MA에 대한 기간 값을 입력하고 표시기에 대한 핸들을 생성하고 표시기 버퍼의 값을 사용하는 경우 우연히 생성되었지만(예를 들어, 이 기본 설정이 있습니다. 형식) 동일한 특성을 가진 2개의 표시기(해당 핸들이 개체 래퍼에 배치됨)는 두 번째 표시기에 대한 이 기능의 결과로 첫 번째 표시기의 핸들 번호를 받습니다.
다음과 같은 가능한 이벤트 체인입니다.
상황 1. 첫 번째 표시기를 삭제하고(프로그램이 IndicatorRelease를 수행함) 두 번째 표시기는 자동으로 작동하지 않습니다. 버퍼 복사 오류입니다.
상황 2. 두 번째 표시기를 제거하고(프로그램이 IndicatorRelease를 수행함) 핸들 카운터가 감소합니다. 첫 느낌이 좋습니다. 기간이 다른 세 번째 지표를 생성합니다. 그는 핸들 카운터+1 즉, 방금 삭제된 표시기의 핸들 번호입니다. 결과적으로 최악의 상황은 성공적으로 생성된 다른 기간의 세 번째 지표가 여전히 삭제되지 않은 첫 번째 지표 의 값을 버퍼링한다는 것 입니다.
핸들 번호 병합 기능으로 인해 병합된 두 핸들 중 하나를 삭제하고 새 핸들을 생성할 때 모호한 상황이 발생합니다.
같은 결과입니다! 이 점에 대한 입력 매개변수는 동일합니다!
명확히 해주세요. "이 포인트에 대한 입력 매개변수가 동일합니다"에 대해 이해하지 못했습니다. 내가 옵티마이저의 작업을 이해하는 한, 각 패스는 고유한 입력 매개변수 세트에 해당합니다. 아니면 유전 알고리즘 을 사용할 때 옵티마이저가 고유한 입력 매개변수 집합을 여러 번 처리할 수 있는 상황이 있을 수 있다고 말하고 싶습니까?
... 글쎄요, 정확히 그 내용입니다. 그런 다음 "캐시에서"모든 후속 점은 최적화 결과의 시각적 인식을 왜곡하는 허구에 불과하다는 것이 밝혀졌습니다.
기이한. 다시 한번. 그래프에는 값이 가까운 두 점이 있고 결과에는 하나만 있습니다.
힌트: 요청된 표시기로 정렬하고 테이블의 수직 스크롤 막대를 표시하는 것을 잊지 마십시오.
과연 이 문제가 해결될까요???
내가 그녀에 대해 이야기하는 것은 이번이 세 번째이고 반응은 제로입니다!
그건 그렇고, requote 모델링을 선택하면 이 캐시를 사용하면 안 되는 것 같습니다. 개발자들은 이에 대해 어떻게 생각합니까?
그리고 또 다른 버그 : 제 유전자 알고리즘 이 10496을 넘어섰을 때 그래프가 잘못 표시되기 시작했습니다. 수직으로 올바르게 확장되었고 더 높은 결과가 발견되었다는 것을 이해할 수 있었지만 수평으로 업데이트되지 않았습니다. 포인트는 이미 그래프의 경계를 넘어 오른쪽 어딘가에 추가된 것처럼 보였습니다.
터미널에서 결과
테스터 결과:
SymbolName(i) 기능의 모든 매력이 사라졌습니다.
개발자에게 요청합니다. MT5에 대한 작업이 한창 진행 중이고 여전히 변경 사항이 적용되는 동안 최적화 패스 수를 늘리는 것이 좋습니다.
내가 이해하는 한 많은 문제에 대한 해결책은 약 10,000개 옵션입니다. 어쩌면 조금 더 많거나 약간 적습니다. 하나의 프로세서에서 몇 시간 동안 검색하면 최상의 옵션을 찾을 수 있습니다.
MQL5+OOP+멀티코어 테스트의 보편성은 MT5를 통해 해결할 수 있는 작업(예: 패턴 검색)의 새로운 지평을 볼 수 있게 해줍니다.
그러나 여기에 문제가 있습니다.
귀하의 사이트에 게시된 기사에는 유전 알고리즘 https://www.mql5.com/ru/articles/55 의 예가 포함되어 있습니다. 여기서 100개 막대에서 검색 문제를 해결하는 데 3^100 직접 열거가 필요합니다. LongInt: )보다 약간 더 많고 17,000번의 반복에서 솔루션을 찾았습니다. 유전 알고리즘은 LongInt보다 더 많은 옵션 중에서 솔루션을 찾을 수 있습니다. 그리고 이 제한은 완전히 불합리하고 구식입니다. 글쎄, MT5 작업의 이 마지막 단계에서 하기가 어려울 것이라는 점을 제외하고.
개발자들에게 큰 부탁인데, 그렇게 어렵지 않다면 패스 횟수를 2^LongInt(2의 제곱) 이상으로 해주세요.
코드:
통나무:
2010.12.06 18:07:52 testInd (EURUSD,H1) 변경? 핸들2=10
2010.12.06 18:07:52 testInd (EURUSD,H1) 핸들2 = 10
2010.12.06 18:07:52 testInd (EURUSD,H1) 핸들1 = 10
따라서 핸들2에 대한 모든 데이터 호출은 기간이 변경되더라도 핸들1에 대한 호출과 동일합니다.
Expert Advisor의 작업 중에 동일한 특성을 가진 표시기 생성이 배제되지 않고 하나의 핸들에 대한 이러한 최적화가 합리적이지만 핸들을 변수에 "고정"하는 것은 수명을 크게 망칩니다.
PS 이유를 찾았습니다. 이것은 하나의 핸들 번호에 대한 최적화의 결과인 버그입니다.
IndicatorRelease (handle2); //уменьшает счетчик хендлов на единицу и в итоге следующий созданный хэндл(с любой переменной) - опять 10
코드:
통나무:
2010.12.06 18:07:52 testInd (EURUSD,H1) 변경? 핸들2=10
2010.12.06 18:07:52 testInd (EURUSD,H1) 핸들2 = 10
2010.12.06 18:07:52 testInd (EURUSD,H1) 핸들1 = 10
따라서 핸들2에 대한 모든 데이터 호출은 기간이 변경되더라도 핸들1에 대한 호출과 동일합니다.
Expert Advisor의 작업 중에 동일한 특성을 가진 표시기 생성이 배제되지 않고 하나의 핸들에 대한 이러한 최적화가 합리적이지만 핸들을 변수에 "고정"하는 것은 수명을 크게 망칩니다.
PS 이유를 찾았습니다. 이것은 하나의 핸들 번호에 대한 최적화의 결과인 버그입니다.
이것이 왜 버그라고 생각합니까?
이것이 왜 버그라고 생각합니까?
예를 들어, 사용자가 인터페이스에서 MA에 대한 기간 값을 입력하고 표시기에 대한 핸들을 생성하고 표시기 버퍼의 값을 사용하는 경우 우연히 생성되었지만(예를 들어, 이 기본 설정이 있습니다. 형식) 동일한 특성을 가진 2개의 표시기(해당 핸들이 개체 래퍼에 배치됨)는 두 번째 표시기에 대한 이 기능의 결과로 첫 번째 표시기의 핸들 번호를 받습니다.
다음과 같은 가능한 이벤트 체인입니다.
상황 1. 첫 번째 표시기를 삭제하고(프로그램이 IndicatorRelease를 수행함) 두 번째 표시기는 자동으로 작동하지 않습니다. 버퍼 복사 오류입니다.
상황 2. 두 번째 표시기를 제거하고(프로그램이 IndicatorRelease를 수행함) 핸들 카운터가 감소합니다. 첫 느낌이 좋습니다. 기간이 다른 세 번째 지표를 생성합니다. 그는 핸들 카운터+1 즉, 방금 삭제된 표시기의 핸들 번호입니다. 결과적으로 최악의 상황은 성공적으로 생성된 다른 기간의 세 번째 지표가 여전히 삭제되지 않은 첫 번째 지표 의 값을 버퍼링한다는 것 입니다.
핸들 번호 병합 기능으로 인해 병합된 두 핸들 중 하나를 삭제하고 새 핸들을 생성할 때 모호한 상황이 발생합니다.
누군가 나에게 대답해 줄까?
그들은 여기에서 그것에 대해 이야기했습니다. https://www.mql5.com/ru/forum/1997/page6/#comment_31644
아마도 질문을 거기로 옮기는 것이 더 나을 것입니다 - 이동 제안.