제 생각에는 최적화 중단을 해결하는 것으로 충분합니다. 중지 버튼을 누를 수 있도록 표를 보고 계속해야 하는지 확인합니다. 그런 다음 실시간으로 결과 테이블을 형성하는 것이 더 이상 중요하지 않습니다. 테이블을 정렬하는 데 리소스가 필요하다는 진술은 나에게 다소 이상하지만 - 어쨌든 패스 캐시는 다른 키로 정렬할 수 있어야 하며 작업 시 어떤 경우에도 정렬됩니다 ...
그러나 이미 말했듯이 최적화 중단이 훨씬 더 중요합니다. 지금 최적화가 다시 시작되는 이유는 명확하지 않습니다. 모든 것이... 분명히 패스 캐시 작업 절차가 재작업되고 있습니다. 그렇지 않으면 최적화를 계속할 가능성이 사라진 것을 설명할 수 없습니다.
제 생각에는 최적화 중단을 해결하는 것으로 충분합니다. 중지 버튼을 누를 수 있도록 표를 보고 계속해야 하는지 확인합니다. 그런 다음 실시간으로 결과 테이블을 형성하는 것이 더 이상 중요하지 않습니다. 테이블을 정렬하는 데 리소스가 필요하다는 진술은 나에게 다소 이상하지만 - 어쨌든 패스 캐시는 다른 키로 정렬할 수 있어야 하며 작업 시 어떤 경우에도 정렬됩니다 ...
그러나 이미 말했듯이 최적화 중단이 훨씬 더 중요합니다. 지금 최적화가 다시 시작되는 이유는 명확하지 않습니다. 모든 것이... 분명히 패스 캐시 작업 절차가 재작업되고 있습니다. 그렇지 않으면 최적화를 계속할 가능성이 사라진 것을 설명할 수 없습니다.
음... 대신 어떤 것이 출시될지 봅시다.
한 대의 컴퓨터에서 테스트하는 동안 동적 테이블로 자유롭게 작업할 수 있습니다. 그러나 타사 에이전트 에 대한 최적화가 있는 경우 테스트 에이전트의 병렬 시작이 있습니다(특히 수십 및 수백(팜)이 있는 경우). 그런 다음 문제가 발생합니다.
제 생각에는 최적화 중단을 해결하는 것으로 충분합니다. 중지 버튼을 누를 수 있도록 표를 보고 계속해야 하는지 확인합니다. 그런 다음 실시간으로 결과 테이블을 형성하는 것이 더 이상 중요하지 않습니다. 테이블을 정렬하는 데 리소스가 필요하다는 진술은 나에게 다소 이상하지만 - 어쨌든 패스 캐시는 다른 키로 정렬할 수 있어야 하며 작업 시 어떤 경우에도 정렬됩니다 ...
그러나 이미 말했듯이 최적화 중단이 훨씬 더 중요합니다. 지금 최적화가 다시 시작되는 이유는 명확하지 않습니다. 모든 것이... 분명히 패스 캐시 작업 절차가 재작업되고 있습니다. 그렇지 않으면 최적화를 계속할 가능성이 사라진 것을 설명할 수 없습니다.
음... 대신 어떤 것이 출시될지 봅시다.
최적화를 중단하면 항상 XX%로 계산된 현재 패스가 다시 계산됩니다.
일시 중단된 패스의 경우 클라우드에 판매하기 위한 코어 사용 또는 다른 테스터의 계산을 차단해서는 안 됩니다.
일시 중단된 패스의 경우 클라우드에 판매하기 위한 코어 사용 또는 다른 테스터의 계산을 차단해서는 안 됩니다.
따라서 평균적으로 현재 패스에서 코어 작업의 절반을 잃게 됩니다.
괜찮은. 중단 시점에 끝까지 수행되지 않은 모든 오산은 랜더마이저에 의해 다시 생성되고 이미 새 데이터 세트에서 다시 계산됩니다. 여기에는 질문이 없습니다.
그러나 이 순간까지 이미 완전히 계산되어 최적화 캐시에 입력된 모든 오산만이 "제자리에 유지"되어야 하며 최적화가 계속되어야 합니다. 그리고 이제 중단되면 최적화가 새로 시작된다는 사실과 매우 유사합니다. 최적화가 15분 동안 지속되면 문제가 되지 않습니다. 그러나 최적화가 15시간 동안 지속된다면 캐시를 잃고 싶지 않을 것입니다.
우리는 절충안을 만들었습니다 . 최적화 결과 탭을 표시하지만 이 탭으로 전환할 때만 업데이트합니다. 즉, 탭에서 결과를 보고 있는 동안 새 결과가 나타나지 않고 테스트 로그로 갔다가 최적화 탭으로 돌아가고 최적화 탭으로 돌아가면 이미 완료된 데이터에 대한 데이터가 통과합니다. 업데이트됩니다.
5월 30일자 빌드 1834가 MetaQuotes-Demo에 게시되었습니다.
이제 최적화 탭에서 실제 최적화 캐시가 있는 경우 이전 최적화 결과를 선택할 수 있습니다. 과거 최적화의 결과를 볼 수 있고 최적화 기준을 변경할 수 있으며(최적화 탭에서) 새로운 수치와 그래프를 볼 수 있으며 과거에 완료되지 않은 최적화를 계속할 수 있습니다.
우리는 절충안을 만들었습니다 . 최적화 결과 탭을 표시하지만 이 탭으로 전환할 때만 업데이트합니다. 즉, 탭에서 결과를 보고 있는 동안 새 결과가 나타나지 않고 테스트 로그로 갔다가 최적화 탭으로 돌아가고 최적화 탭으로 돌아가면 이미 완료된 데이터에 대한 데이터가 통과합니다. 업데이트됩니다.
5월 30일자 빌드 1834가 MetaQuotes-Demo에 게시되었습니다.
이제 최적화 탭에서 실제 최적화 캐시가 있는 경우 이전 최적화 결과를 선택할 수 있습니다. 과거 최적화의 결과를 볼 수 있고 최적화 기준을 변경할 수 있으며(최적화 탭에서) 새로운 수치와 그래프를 볼 수 있으며 과거에 완료되지 않은 최적화를 계속할 수 있습니다.
자, 배송, 연간 기간, 모든 매개변수 열거에서 표준 이사 전문가 - 최소한 Google의 옵션을 쉽게 얻을 수 있습니다! :-)
이것의 실용적인 용도는 무엇입니까?
최적화 결과 를 본 각 개발자는 첫 번째 줄부터 계속할지 여부를 결정합니다. 따라서 최적화가 끝나기 전에 중단 없이 결과를 볼 수 있는 기회를 제공해야 합니다.
"최적화 결과" 탭이 반환되어야 하며 "테이블 업데이트" 버튼이 테이블 상단에 추가될 수 있습니다.
그것은 더 의미가있을 것입니다.
+100500
이제 최적화는 "포켓에 돼지"를 사는 것과 같습니다!
모든 것이 슬프다.
제 생각에는 최적화 중단을 해결하는 것으로 충분합니다. 중지 버튼을 누를 수 있도록 표를 보고 계속해야 하는지 확인합니다. 그런 다음 실시간으로 결과 테이블을 형성하는 것이 더 이상 중요하지 않습니다. 테이블을 정렬하는 데 리소스가 필요하다는 진술은 나에게 다소 이상하지만 - 어쨌든 패스 캐시는 다른 키로 정렬할 수 있어야 하며 작업 시 어떤 경우에도 정렬됩니다 ...
그러나 이미 말했듯이 최적화 중단이 훨씬 더 중요합니다. 지금 최적화가 다시 시작되는 이유는 명확하지 않습니다. 모든 것이... 분명히 패스 캐시 작업 절차가 재작업되고 있습니다. 그렇지 않으면 최적화를 계속할 가능성이 사라진 것을 설명할 수 없습니다.
음... 대신 어떤 것이 출시될지 봅시다.
제 생각에는 최적화 중단을 해결하는 것으로 충분합니다. 중지 버튼을 누를 수 있도록 표를 보고 계속해야 하는지 확인합니다. 그런 다음 실시간으로 결과 테이블을 형성하는 것이 더 이상 중요하지 않습니다. 테이블을 정렬하는 데 리소스가 필요하다는 진술은 나에게 다소 이상하지만 - 어쨌든 패스 캐시는 다른 키로 정렬할 수 있어야 하며 작업 시 어떤 경우에도 정렬됩니다 ...
그러나 이미 말했듯이 최적화 중단이 훨씬 더 중요합니다. 지금 최적화가 다시 시작되는 이유는 명확하지 않습니다. 모든 것이... 분명히 패스 캐시 작업 절차가 재작업되고 있습니다. 그렇지 않으면 최적화를 계속할 가능성이 사라진 것을 설명할 수 없습니다.
음... 대신 어떤 것이 출시될지 봅시다.
한 대의 컴퓨터에서 테스트하는 동안 동적 테이블로 자유롭게 작업할 수 있습니다. 그러나 타사 에이전트 에 대한 최적화가 있는 경우 테스트 에이전트의 병렬 시작이 있습니다(특히 수십 및 수백(팜)이 있는 경우). 그런 다음 문제가 발생합니다.
제 생각에는 최적화 중단을 해결하는 것으로 충분합니다. 중지 버튼을 누를 수 있도록 표를 보고 계속해야 하는지 확인합니다. 그런 다음 실시간으로 결과 테이블을 형성하는 것이 더 이상 중요하지 않습니다. 테이블을 정렬하는 데 리소스가 필요하다는 진술은 나에게 다소 이상하지만 - 어쨌든 패스 캐시는 다른 키로 정렬할 수 있어야 하며 작업 시 어떤 경우에도 정렬됩니다 ...
그러나 이미 말했듯이 최적화 중단이 훨씬 더 중요합니다. 지금 최적화가 다시 시작되는 이유는 명확하지 않습니다. 모든 것이... 분명히 패스 캐시 작업 절차가 재작업되고 있습니다. 그렇지 않으면 최적화를 계속할 가능성이 사라진 것을 설명할 수 없습니다.
음... 대신 어떤 것이 출시될지 봅시다.
최적화를 중단하면 항상 XX%로 계산된 현재 패스가 다시 계산됩니다.
일시 중단된 패스의 경우 클라우드에 판매하기 위한 코어 사용 또는 다른 테스터의 계산을 차단해서는 안 됩니다.
따라서 평균적으로 현재 패스에서 코어 작업의 절반을 잃게 됩니다.
최적화를 중단하면 항상 XX%로 계산된 현재 패스가 다시 계산됩니다.
일시 중단된 패스의 경우 클라우드에 판매하기 위한 코어 사용 또는 다른 테스터의 계산을 차단해서는 안 됩니다.
따라서 평균적으로 현재 패스에서 코어 작업의 절반을 잃게 됩니다.
괜찮은. 중단 시점에 끝까지 수행되지 않은 모든 오산은 랜더마이저에 의해 다시 생성되고 이미 새 데이터 세트에서 다시 계산됩니다. 여기에는 질문이 없습니다.
그러나 이 순간까지 이미 완전히 계산되어 최적화 캐시에 입력된 모든 오산만이 "제자리에 유지"되어야 하며 최적화가 계속되어야 합니다. 그리고 이제 중단되면 최적화가 새로 시작된다는 사실과 매우 유사합니다. 최적화가 15분 동안 지속되면 문제가 되지 않습니다. 그러나 최적화가 15시간 동안 지속된다면 캐시를 잃고 싶지 않을 것입니다.
이것은 완전한 파이퍼입니다 ... 25 패스의 최적화, M1의 OHLC는 2 시간 이상 걸렸습니다 ...
시원한!...
우리는 절충안을 만들었습니다 . 최적화 결과 탭을 표시하지만 이 탭으로 전환할 때만 업데이트합니다. 즉, 탭에서 결과를 보고 있는 동안 새 결과가 나타나지 않고 테스트 로그로 갔다가 최적화 탭으로 돌아가고 최적화 탭으로 돌아가면 이미 완료된 데이터에 대한 데이터가 통과합니다. 업데이트됩니다.
5월 30일자 빌드 1834가 MetaQuotes-Demo에 게시되었습니다.
이제 최적화 탭에서 실제 최적화 캐시가 있는 경우 이전 최적화 결과를 선택할 수 있습니다. 과거 최적화의 결과를 볼 수 있고 최적화 기준을 변경할 수 있으며(최적화 탭에서) 새로운 수치와 그래프를 볼 수 있으며 과거에 완료되지 않은 최적화를 계속할 수 있습니다.
우리는 절충안을 만들었습니다 . 최적화 결과 탭을 표시하지만 이 탭으로 전환할 때만 업데이트합니다. 즉, 탭에서 결과를 보고 있는 동안 새 결과가 나타나지 않고 테스트 로그로 갔다가 최적화 탭으로 돌아가고 최적화 탭으로 돌아가면 이미 완료된 데이터에 대한 데이터가 통과합니다. 업데이트됩니다.
5월 30일자 빌드 1834가 MetaQuotes-Demo에 게시되었습니다.
이제 최적화 탭에서 실제 최적화 캐시가 있는 경우 이전 최적화 결과를 선택할 수 있습니다. 과거 최적화의 결과를 볼 수 있고 최적화 기준을 변경할 수 있으며(최적화 탭에서) 새로운 수치와 그래프를 볼 수 있으며 과거에 완료되지 않은 최적화를 계속할 수 있습니다.
정말 감사합니다!