최신 빌드에서는 작업 시작 시 시스템 오버헤드를 완전히 제거하여 거의 2000ms에서 0으로 줄였습니다.
joo가 제안한 계산 작업을 실행한 결과는 다음과 같습니다.
설정(날짜는 차트 기록이 사용되지 않도록 특별히 설정됨):
반복 매개변수:
사용된 에이전트(로컬 에이전트 4개):
최적화 결과:
최적화는 단 25초가 걸렸고 18,432개의 패스가 만들어졌습니다.
결론: MetaTrader 5와 에이전트 네트워크는 방대한 수학적 계산에 사용할 수 있습니다.
이것은 매우 좋은 결과입니다. 이제 실제로 옵티마이저는 최적화 문제(거래 및 거래와 직접 관련되지 않음)를 해결하는 데 다소 적합합니다. 옵티마이저의 기본 GA 설정을 사용하여 특히 이 작업에 대해 패스 수가 2-3,000개로 감소하면 결과가 훨씬 더 좋을 것이지만 이를 위해서는 사용자 액세스에 대한 GA 설정을 표시해야 합니다(다음과 같은 경우 가능합니다. 사용자는 패스 수를 500-900으로 줄이기를 원합니다) .
검색 공간의 제한과 관련된 문제가 남아 있습니다. 옵티마이저에 대한 해당 제안이 서비스 데스크에서 발행되었습니다.
이것은 매우 좋은 결과입니다. 이제 실제로 옵티마이저는 최적화 문제(거래 및 거래와 직접 관련되지 않음)를 해결하는 데 다소 적합합니다. 옵티마이저의 기본 GA 설정을 사용하여 특히 이 작업에 대해 패스 수가 2-3,000개로 감소하면 결과가 훨씬 더 좋을 것이지만 이를 위해서는 사용자 액세스에 대한 GA 설정을 표시해야 합니다(다음과 같은 경우 가능합니다. 사용자는 패스 수를 500-900으로 줄이기를 원합니다) .
검색 공간의 제한과 관련된 문제가 남아 있습니다 . 옵티마이저에 대한 해당 제안이 서비스 데스크에서 발행되었습니다.
그리고 이 문제에 대한 해결책은 주로 이 문제와 관련이 있습니다.
최적화 패스의 오버플로가 이미 4개의 매개변수에서 발생했다면 지금 허용되는 것(64개)보다 많은 매개변수의 수를 늘리는 것에 대해 이야기하는 것은 아직 적절하지 않습니다.
최적화 패스의 오버플로가 이미 4개의 매개변수에서 발생했다면 지금 허용되는 것(64개)보다 많은 매개변수의 수를 늘리는 것에 대해 이야기하는 것은 아직 적절하지 않습니다.
당연하지. 대략적으로 검색 공간은 P=n*step입니다. 여기서 n은 최적화할 매개변수의 수이고 step은 매개변수의 단계입니다. 이 경우 공간 P는 공간 Pmax(염색체의 이진 인코딩의 기능에 의해 제한되는 가능한 최대 검색 공간)보다 작아야 합니다. 따라서 인위적으로 도입된 제한 중 하나(결국, 예를 들어 10,000개의 매개변수에 제한을 두는 것이 가능하지만 대부분의 최적화 문제를 해결하는 데 필요한 것보다 단계가 더 큼), 따라서 P가 Pmax를 초과하지 않도록 , n에 대한 제한이 도입되었습니다.
이 문제에 대한 생각은 서비스 데스크의 옵티마이저에 대한 제안서에 나와 있습니다.
추신: 원격 에이전트 네트워크의 성장과 함께 많은 수의 실행 문제가 사라지고 있습니다. 그러나 물론 염색체의 이진 코딩에 대한 제한이 제거 된 경우에만 (우리는 읽습니다-실수로 염색체 인코딩으로의 전환).
당연하지. 대략적으로, 검색 공간은 P=n*step 입니다. 여기서 n은 최적화할 매개변수의 수이고 step은 매개변수의 단계입니다. 이 경우 공간 P는 공간 Pmax(염색체의 이진 인코딩의 기능에 의해 제한되는 가능한 최대 검색 공간)보다 작아야 합니다. 따라서 인위적으로 도입된 제한 중 하나(결국, 예를 들어 10,000개의 매개변수에 제한을 두는 것이 가능하지만 대부분의 최적화 문제를 해결하는 데 필요한 것보다 단계가 더 큼), 따라서 P가 Pmax를 초과하지 않도록 , n에 대한 제한이 도입되었습니다.
이 문제에 대한 생각은 서비스 데스크의 옵티마이저에 대한 제안서에 나와 있습니다.
추신: 원격 에이전트 네트워크의 성장과 함께 많은 수의 실행 문제가 사라지고 있습니다. 그러나 물론 염색체의 이진 코딩에 대한 제한이 제거 된 경우에만 (우리는 읽습니다-실수로 염색체 인코딩으로의 전환).
약간 잘못되었습니다. 올바른 수의 옵션은 다음과 같이 간주됩니다. P=step_0*step_1*...*step_n
최신 빌드에서는 작업 시작 시 시스템 오버헤드를 완전히 제거하여 거의 2000ms에서 0으로 줄였습니다.
공상! 아, 여름에 최적화에 얼마나 많은 시간을 헛되이 보냈는지 ...
순서대로. 현재 빌드와 319번째 빌드(2010년 9월 2일)에서 joo에서 테스트를 실행했습니다. 결과:
2010.12.29 15:49:18 테스터 최적화 2분 41초만에 통과 2010.12.29 15:49:18 15360(100000020000001)을 통과하여 테스터 유전자 최적화 완료 2010.12.29 15:49:18 테스터 결과 캐시 7265회 사용 2010.12.29 15:49:13 테스터 유전학은 끝났다
2010.12.29 17:10:59 테스터 최적화 1시간 17분 34초만에 통과 2010.12.29 17:10:59 테스터 유전자 최적화 18176 통과 (of 100000020000001) 2010.12.29 17:10:59 테스터 결과 캐시 10582회 사용 2010.12.29 17:10:52 테스터 유전학은 끝났다
순서대로. 현재 빌드와 319번째 빌드(2010년 9월 2일)에서 joo에서 테스트를 실행했습니다. 결과:
2010.12.29 15:49:18 테스터 최적화 2분 41초만에 통과 2010.12.29 15:49:18 15360(100000020000001)을 통과하여 테스터 유전자 최적화 완료 2010.12.29 15:49:18 테스터 결과 캐시 7265회 사용 2010.12.29 15:49:13 테스터 유전학은 끝났다
2010.12.29 17:10:59 테스터 최적화 1시간 17분 34초만에 통과 2010.12.29 17:10:59 테스터 유전자 최적화 18176 통과 (of 100000020000001) 2010.12.29 17:10:59 테스터 결과 캐시 10582회 사용 2010.12.29 17:10:52 테스터 유전학은 끝났다
축하해야 할지 감사해야 할지조차 모르겠다. 고맙습니다!
"터미널에서 에이전트로 초기 데이터 동기화/전송 및 에이전트에서 결과 수신" 단계에서 시스템 오버헤드를 줄여 각 실행 시 1.5-2초를 절약했습니다. 언어 의 계산 가속은 발생하지 않았습니다.
즉, 계산 시간이 거의 0에 가까운 속사 오류 계산에 가장 심각한 영향을 줍니다. 대규모 컴퓨팅의 경우 절감 효과가 그렇게 두드러지지 않습니다. 10,000번의 시작당 2초를 절약하면 20,000초 = 333분 = 5.5시간이 됩니다.
그리고 나는 그것이 영향을 미친다는 것을 알아차렸습니다. 나는 평일에 EA를 실행했고 지금은 확장된 스프레드로 실행했습니다. 결과는 상당히 다릅니다. 유로백의 스프레드는 이제 약 4포인트(4자리)입니다. 주말 스프레드의 '고착'도 MT5에서 사라졌다는 뜻이다. 따라서 최적화가 올바르지 않으므로 주말에 최적화할 가치가 없습니다. MT4에서도 시각적으로 볼 수 있습니다. EA는 그 월요일부터 최적화를 진행하고 있었고 결과 곡선은 주말 이후로 내려갔습니다. 이는 스프레드가 최적화 결과 에 영향을 미치고 더 나빠졌음을 나타냅니다.
최신 빌드에서는 작업 시작 시 시스템 오버헤드를 완전히 제거하여 거의 2000ms에서 0으로 줄였습니다.
joo가 제안한 계산 작업을 실행한 결과는 다음과 같습니다.
설정(날짜는 차트 기록이 사용되지 않도록 특별히 설정됨):
반복 매개변수:
사용된 에이전트(로컬 에이전트 4개):
최적화 결과:
최적화는 단 25초가 걸렸고 18,432개의 패스가 만들어졌습니다.
결론: MetaTrader 5와 에이전트 네트워크는 방대한 수학적 계산에 사용할 수 있습니다.
최신 빌드에서는 작업 시작 시 시스템 오버헤드를 완전히 제거하여 거의 2000ms에서 0으로 줄였습니다.
joo가 제안한 계산 작업을 실행한 결과는 다음과 같습니다.
설정(날짜는 차트 기록이 사용되지 않도록 특별히 설정됨):
반복 매개변수:
사용된 에이전트(로컬 에이전트 4개):
최적화 결과:
최적화는 단 25초가 걸렸고 18,432개의 패스가 만들어졌습니다.
결론: MetaTrader 5와 에이전트 네트워크는 방대한 수학적 계산에 사용할 수 있습니다.
이것은 매우 좋은 결과입니다. 이제 실제로 옵티마이저는 최적화 문제(거래 및 거래와 직접 관련되지 않음)를 해결하는 데 다소 적합합니다. 옵티마이저의 기본 GA 설정을 사용하여 특히 이 작업에 대해 패스 수가 2-3,000개로 감소하면 결과가 훨씬 더 좋을 것이지만 이를 위해서는 사용자 액세스에 대한 GA 설정을 표시해야 합니다(다음과 같은 경우 가능합니다. 사용자는 패스 수를 500-900으로 줄이기를 원합니다) .
검색 공간의 제한과 관련된 문제가 남아 있습니다. 옵티마이저에 대한 해당 제안이 서비스 데스크에서 발행되었습니다.
이것은 매우 좋은 결과입니다. 이제 실제로 옵티마이저는 최적화 문제(거래 및 거래와 직접 관련되지 않음)를 해결하는 데 다소 적합합니다. 옵티마이저의 기본 GA 설정을 사용하여 특히 이 작업에 대해 패스 수가 2-3,000개로 감소하면 결과가 훨씬 더 좋을 것이지만 이를 위해서는 사용자 액세스에 대한 GA 설정을 표시해야 합니다(다음과 같은 경우 가능합니다. 사용자는 패스 수를 500-900으로 줄이기를 원합니다) .
검색 공간의 제한과 관련된 문제가 남아 있습니다 . 옵티마이저에 대한 해당 제안이 서비스 데스크에서 발행되었습니다.
그리고 이 문제에 대한 해결책은 주로 이 문제와 관련이 있습니다.
최적화 패스의 오버플로가 이미 4개의 매개변수에서 발생했다면 지금 허용되는 것(64개)보다 많은 매개변수의 수를 늘리는 것에 대해 이야기하는 것은 아직 적절하지 않습니다.
그리고 이 문제에 대한 해결책은 주로 이 문제와 관련이 있습니다.
최적화 패스의 오버플로가 이미 4개의 매개변수에서 발생했다면 지금 허용되는 것(64개)보다 많은 매개변수의 수를 늘리는 것에 대해 이야기하는 것은 아직 적절하지 않습니다.
당연하지. 대략적으로 검색 공간은 P=n*step입니다. 여기서 n은 최적화할 매개변수의 수이고 step은 매개변수의 단계입니다. 이 경우 공간 P는 공간 Pmax(염색체의 이진 인코딩의 기능에 의해 제한되는 가능한 최대 검색 공간)보다 작아야 합니다. 따라서 인위적으로 도입된 제한 중 하나(결국, 예를 들어 10,000개의 매개변수에 제한을 두는 것이 가능하지만 대부분의 최적화 문제를 해결하는 데 필요한 것보다 단계가 더 큼), 따라서 P가 Pmax를 초과하지 않도록 , n에 대한 제한이 도입되었습니다.
이 문제에 대한 생각은 서비스 데스크의 옵티마이저에 대한 제안서에 나와 있습니다.
추신: 원격 에이전트 네트워크의 성장과 함께 많은 수의 실행 문제가 사라지고 있습니다. 그러나 물론 염색체의 이진 코딩에 대한 제한이 제거 된 경우에만 (우리는 읽습니다-실수로 염색체 인코딩으로의 전환).
당연하지. 대략적으로, 검색 공간은 P=n*step 입니다. 여기서 n은 최적화할 매개변수의 수이고 step은 매개변수의 단계입니다. 이 경우 공간 P는 공간 Pmax(염색체의 이진 인코딩의 기능에 의해 제한되는 가능한 최대 검색 공간)보다 작아야 합니다. 따라서 인위적으로 도입된 제한 중 하나(결국, 예를 들어 10,000개의 매개변수에 제한을 두는 것이 가능하지만 대부분의 최적화 문제를 해결하는 데 필요한 것보다 단계가 더 큼), 따라서 P가 Pmax를 초과하지 않도록 , n에 대한 제한이 도입되었습니다.
이 문제에 대한 생각은 서비스 데스크의 옵티마이저에 대한 제안서에 나와 있습니다.
추신: 원격 에이전트 네트워크의 성장과 함께 많은 수의 실행 문제가 사라지고 있습니다. 그러나 물론 염색체의 이진 코딩에 대한 제한이 제거 된 경우에만 (우리는 읽습니다-실수로 염색체 인코딩으로의 전환).
약간 잘못되었습니다. 올바른 수의 옵션은 다음과 같이 간주됩니다. P=step_0* step_1*...* step_n
단계 크기가 같으면 P=step^n 이 됩니다.
약간 잘못되었습니다. 올바른 수의 옵션은 다음과 같이 간주됩니다. P=step_0* step_1*...* step_n
단계 크기가 같으면 P=step^n 이 됩니다.
최신 빌드에서는 작업 시작 시 시스템 오버헤드를 완전히 제거하여 거의 2000ms에서 0으로 줄였습니다.
공상! 아, 여름에 최적화에 얼마나 많은 시간을 헛되이 보냈는지 ...
순서대로. 현재 빌드와 319번째 빌드(2010년 9월 2일)에서 joo에서 테스트를 실행했습니다. 결과:
2010.12.29 15:49:18 15360(100000020000001)을 통과하여 테스터 유전자 최적화 완료
2010.12.29 15:49:18 테스터 결과 캐시 7265회 사용
2010.12.29 15:49:13 테스터 유전학은 끝났다
2010.12.29 17:10:59 테스터 유전자 최적화 18176 통과 (of 100000020000001)
2010.12.29 17:10:59 테스터 결과 캐시 10582회 사용
2010.12.29 17:10:52 테스터 유전학은 끝났다
축하해야 할지 감사해야 할지조차 모르겠습니다. 고맙습니다!
그리고 이 문제에 대한 해결책은 주로 이 문제와 관련이 있습니다.
최적화 패스의 오버플로가 이미 4개의 매개변수에서 발생했다면 지금 허용되는 것(64개)보다 많은 매개변수의 수를 늘리는 것에 대해 이야기하는 것은 아직 적절하지 않습니다.
검색에 합리적인 접근 방식을 사용하되 "러시아 남자가 일본 전기톱을 부수다" 모드에서 핸들을 최대로 비틀지 마십시오.
실제 작업에서 유전자 최적화를 적용하기 시작하자마자 합리적인 한계를 선택하기 시작합니다.
공상! 아, 여름에 최적화에 얼마나 많은 시간을 헛되이 보냈는지 ...
순서대로. 현재 빌드와 319번째 빌드(2010년 9월 2일)에서 joo에서 테스트를 실행했습니다. 결과:
2010.12.29 15:49:18 15360(100000020000001)을 통과하여 테스터 유전자 최적화 완료
2010.12.29 15:49:18 테스터 결과 캐시 7265회 사용
2010.12.29 15:49:13 테스터 유전학은 끝났다
2010.12.29 17:10:59 테스터 유전자 최적화 18176 통과 (of 100000020000001)
2010.12.29 17:10:59 테스터 결과 캐시 10582회 사용
2010.12.29 17:10:52 테스터 유전학은 끝났다
축하해야 할지 감사해야 할지조차 모르겠다. 고맙습니다!
"터미널에서 에이전트로 초기 데이터 동기화/전송 및 에이전트에서 결과 수신" 단계에서 시스템 오버헤드를 줄여 각 실행 시 1.5-2초를 절약했습니다. 언어 의 계산 가속은 발생하지 않았습니다.
즉, 계산 시간이 거의 0에 가까운 속사 오류 계산에 가장 심각한 영향을 줍니다. 대규모 컴퓨팅의 경우 절감 효과가 그렇게 두드러지지 않습니다. 10,000번의 시작당 2초를 절약하면 20,000초 = 333분 = 5.5시간이 됩니다.
영향을 미치지 않습니다.
그리고 나는 그것이 영향을 미친다는 것을 알아차렸습니다. 나는 평일에 EA를 실행했고 지금은 확장된 스프레드로 실행했습니다. 결과는 상당히 다릅니다. 유로백의 스프레드는 이제 약 4포인트(4자리)입니다. 주말 스프레드의 '고착'도 MT5에서 사라졌다는 뜻이다. 따라서 최적화가 올바르지 않으므로 주말에 최적화할 가치가 없습니다. MT4에서도 시각적으로 볼 수 있습니다. EA는 그 월요일부터 최적화를 진행하고 있었고 결과 곡선은 주말 이후로 내려갔습니다. 이는 스프레드가 최적화 결과 에 영향을 미치고 더 나빠졌음을 나타냅니다.