물론 여기서 메소드 호출과 함께 이 메소드를 원격으로 호출하는 객체 필드의 현재 값을 에이전트에 전송해야 합니다.
결론은 클래스의 메인 인스턴스가 일종의 메소드를 호출하고 메소드 내부에 다른 클래스의 인스턴스가 생성되어 작업을 클라우드로 보내는 것입니다. 결과가 반환됩니다.
예를 들어, 작업은 체스에서 여러 움직임을 잘못 계산하는 형태로 생성됩니다. 원격으로 실행되는 메인 메소드에서는 한 번의 움직임에 대해 오산으로 다양한 조합이 생성되어 특정 클래스의 객체 형태로 발송됩니다. 이동이 결과로 끝나지 않았거나 계산 깊이가 한계를 초과하지 않은 경우 동일한 방법을 다시 호출합니다. 등. 등.
bool FrameSend( constlong agent, // номер агента, или BROADCASTconststring name, // публичное имя/меткаconstlong id, // публичный idconstdoublevalue , // значениеconststring filename // имя файла с данными
);
정보를 위한 경우:
네트워크 지연 비용은 전체 프로세스를 최적화하기 위해 결과를 명시적으로 패키징하고 가능한 한 적은 데이터를 전송해야 하는 것과 같습니다. 예를 들어, 100,000,000 패스에 대해 빠르게 발생하는(1초 미만) 수학 문제가 있는 경우 최적화 프로세스를 즉시 1,000-10,000 패스의 부분으로 알고리즘 방식으로 배포하고 결과와 함께 그룹 처리 코드를 작성하는 것이 좋습니다. 일괄 반환됩니다. 이것은 네트워크에서 많은 시간이 소요되는 100,000,000회 반환에 비해 큰 이점을 제공합니다.
우리 쪽에서는 속사급 작업의 경우 각 에이전트에 수십 및 수백 개의 패스 발급과 응답 번들링을 함께 심각하게 지원합니다. 그 결과 네트워크 전송이 크게 절약되고 네트워크 대기 시간이 최소화됩니다.
아니요, 데이터 프레임을 교환하는 유일한 실제 옵션이 있습니다. 기능의 원격 실행은 심각하지 않습니다. 올바른 마음을 가진 사람은 정보 환경을 복제할 수 없기 때문입니다.
모든 작업에서 결과를 패키징할 수 있는 것은 아닙니다. 일부 응용 프로그램과 리소스 집약적 인 경우 결과가 유일한 것일 수도 있고 전혀 발견되지 않을 수도 있으며 실패한 작업은 재생 과정에서 폐기됩니다. 누락된 결과는 반환할 필요조차 없습니다.
그러면 다르게 할 수 있습니다. 즉, 주요 작업은 측면에서 작업을 생성하고 에이전트에게 이에 대해 알립니다. 그리고 에이전트는 작업과 함께 원격 메서드를 호출하고 계산하고 결과가 나오면 원격 메서드를 호출하여 결과를 반환합니다.
예를 들어, 문제: 페르마 수의 소수를 찾는 것. 결과가 전혀 없을 수도 있고, 하나 또는 여러 개일 수도 있습니다. 결론은 이러한 동일한 잠재적 제수를 열거하는 것은 매우 자원 집약적인 작업이라는 것입니다. 먼저 큰 수의 형태로 개체를 만들어야 합니다(작업에서 정보 전송 비용을 줄이기 위해 정수 형식으로 두 개의 숫자만 지정할 수 있습니다: 주와 가수). 그런 다음 단순성을 위해 이 숫자를 확인합니다(단순한 확인이 수행되어 숫자가 소수가 아닌 90% 이상임을 알 수 있음). 그런 다음 단순성 테스트가 성공적으로 통과되면 루프에서 모듈로를 제곱하여 조건의 일치를 찾습니다. 루프가 끝나기 전에 조건이 일치하지 않으면 결과가 없고 반환할 것이 없습니다. 이 경우 에이전트는 메인 애플리케이션에서 원격으로 적절한 메소드를 호출하여 원격으로 다음 작업을 요청해야 합니다. 결과를 찾으면 다른 메서드를 호출하고 동일한 결과를 전달해야 합니다.
저것들. 작업이 다르고 프레임 구조가 모든 사람에게 적합하지 않습니다. 그리고 위의 예에서 네트워크 지연 비용도 무시할 수 있습니다. 하나의 작업은 두 개의 정수를 에이전트에 전달하는 것으로 구성됩니다.
그래서 이것은 단지 기초입니다. 주요 작업과 계산에 리소스를 매우 많이 사용하는 작업은 재귀적입니다. 그리고 클라우드는 그러한 작업을 위한 것이 아닙니다. 그것은 철저한 열거를 위해서만 만들어집니다. 전체 열거는 많은 적용 문제에서 사용되지 않습니다. 그는 희망이 없습니다. 너비가 있는 깊이 우선 검색과 너비가 있는 깊이 우선 검색에는 재귀 작업이 필요합니다. 예를 들어, 분자의 합성. 저것들. 플레이 과정에서 잠재적인 솔루션 트리가 구축되며, 각 분기는 컴퓨팅 리소스를 많이 사용합니다. 그러나 모든 지점이 생산적인 것은 아닙니다. 저것들. 어딘가에서 검색이 중단되지만 동시에 깊이나 폭이 다른 잠재적인 분기에서 검색이 계속됩니다.
전체 열거는 실제로 사용되지 않습니다. 대부분의 적용된 문제의 경우 해결책을 찾는 데 시간이 충분하지 않습니다(예: 체스 게임의 움직임을 분석하는 문제). 그리고 유망하지 않은 의사결정 분기의 가지치기를 사용한 재귀적 방법은 특히 분산 컴퓨팅 에서 고속을 제공합니다. 따라서 응용 프로그램을 클라우드로 끌어들이려면 이 클라우드를 작업에 맞게 조정해야 하며, 모든 것을 포기하고 잠재 고객에 관계없이 모든 옵션을 연속적으로 정렬할 것이라고 생각해서는 안 됩니다. 기가플롭과 적은 수의 컴퓨터로 속도가 느리기는 하지만 분산 컴퓨팅의 자체 네트워크를 만드는 것이 더 쉬울 것입니다. 유망한 방향으로만 검색하고 Cloud Network보다 훨씬 빠르게 올바른 솔루션을 찾을 것입니다. 또한 많은 프로그래밍 언어에는 이를 위한 도구가 있습니다. 기성품 RPC 구현.
예를 들어, 페르마 수의 소수 제수에 대한 동일한 검색은 하위 문제로 나눌 수 있습니다. 기본 응용 프로그램은 작업을 생성합니다. 다음 계층은 객체를 만들고 나머지에서 빠른 우선 순위 검사를 수행하여 작업을 형성합니다. 다음 레이어는 조건을 찾습니다. 페르마 수의 제수를 찾거나 찾지 못함. 작업은 감지된 숫자로 다시 구성됩니다. 다음 계층은 소수에 대한 전체 검사를 수행하고 숫자가 소수가 아니면 작업을 생성합니다. 단순하면 결과를 기본 응용 프로그램에 반환합니다. 다음 층은 페르마 수의 소수가 아닌 약수를 인수분해하고 그로부터 이전 층에 대한 할당을 형성합니다.
에이전트가 각 계층에서 작업을 수행하는 컨베이어가 나타납니다. 그리고 결과를 찾을 수 있는지 여부는 갈퀴로 작성됩니다. 솔루션에 대한 추가 검색을 위해 분명히 유망하지 않은 숫자는 파이프라인에서 폐기하는 것이 중요합니다. 저것들. 많은 컴퓨팅 리소스가 절약되고 수천 명의 에이전트를 약속 없는 작업에 쌓아서 분쇄하려고 시도하지 않습니다.
그래서 이것은 단지 기초입니다. 주요 작업과 계산에 리소스를 매우 많이 사용하는 작업은 재귀적입니다. 그리고 클라우드는 그러한 작업을 위한 것이 아닙니다. 그것은 철저한 열거를 위해서만 만들어집니다. 전체 열거는 많은 적용 문제에서 사용되지 않습니다. 그는 희망이 없습니다. 너비가 있는 깊이 우선 검색과 너비가 있는 깊이 우선 검색에는 재귀 작업이 필요합니다. 예를 들어, 분자의 합성. 저것들. 플레이 과정에서 잠재적인 솔루션 트리가 구축되며, 각 분기는 컴퓨팅 리소스를 많이 사용합니다. 그러나 모든 지점이 생산적인 것은 아닙니다. 저것들. 어딘가에서 검색이 중단되지만 동시에 깊이나 폭이 다른 잠재적인 분기에서 검색이 계속됩니다.
1,000-10,000 패스의 배치를 실행하고 의미 있는 결과만 반환합니다. 이것은 매우 효율적인 알고리즘 기술입니다.
나는 위에서 이것에 대해 구체적으로 썼습니다.
전체 열거는 실제로 사용되지 않습니다. 대부분의 적용된 문제의 경우 해결책을 찾는 데 시간이 충분하지 않습니다(예: 체스 게임의 움직임을 분석하는 문제). 그리고 유망하지 않은 의사결정 분기의 가지치기를 사용하는 재귀적 방법은 특히 분산 컴퓨팅 에서 고속을 제공합니다. 따라서 응용 프로그램을 클라우드로 끌어들이려면 이 클라우드를 작업에 맞게 조정해야 하며 잠재 고객에 관계없이 모든 옵션을 삭제하고 모든 옵션을 연속적으로 정렬할 것이라고 생각해서는 안 됩니다. 기가플롭과 더 적은 수의 컴퓨터로 덜 빠르게 실행되지만 더 효율적이기 때문에 분산 컴퓨팅의 자체 네트워크를 만드는 것이 더 쉬울 것입니다. 유망한 방향으로만 검색하고 Cloud Network보다 훨씬 빠르게 올바른 솔루션을 찾을 것입니다. 또한 많은 프로그래밍 언어에는 이를 위한 도구가 있습니다. 기성품 RPC 구현.
예를 들어, 페르마 수의 소수 제수에 대한 동일한 검색은 하위 문제로 나눌 수 있습니다. 기본 응용 프로그램은 작업을 생성합니다. 다음 계층은 객체를 생성하고 나머지에서 빠른 우선 순위 검사를 수행하여 작업을 형성합니다. 다음 레이어는 조건을 찾습니다. 페르마 수의 제수를 찾거나 찾지 못함. 작업은 감지된 숫자로 다시 구성됩니다. 다음 계층은 소수에 대한 전체 검사를 수행하고 숫자가 소수가 아니면 작업을 생성합니다. 단순하면 결과를 기본 응용 프로그램에 반환합니다. 다음 층은 페르마 수의 소수가 아닌 제수를 인수분해하고 그로부터 이전 층에 대한 할당을 형성합니다.
데이터 교환 및 데모에 대해 위에서 읽으십시오.
에이전트의 작업을 제어하는 마스터 프로세스가 이미 있습니다. 차트에 위치하며 에이전트로부터 프레임(대형 사용자 정의 크기)을 수신합니다.
마스터 프로세스는 수신된 사용자 정의 데이터를 이미 수신, 시각화, 처리 및 저장할 수 있습니다.
마스터 프로세스가 추가 사용자 지정 데이터인 모든 에이전트에 데이터를 추가로 전송할 수 있도록 데이터 교환을 더욱 확장하는 것이 제안됩니다. 결과적으로 원격 에이전트에 새로운 사용자 지정 조건을 제공하는 부분만 고려할 수 있습니다. 결과적으로 적어도 문제의 조건을 변경할 때마다 원하는 대로 계산할 수 있습니다.
에이전트가 마스터로부터 작업을 수신할 수 있을 뿐만 아니라 서로 데이터를 교환할 수 있는 경우 가능한 확장 중 하나입니다. 물론 이 작업은 마법사를 통해 수행할 수 있지만(데이터가 많은 경우 매우 느릴 수 있음) 클라우드 서버를 통해 직접 훨씬 더 효율적이고 빠르게 수행할 수 있습니다.
에이전트가 마스터로부터 작업을 수신할 수 있을 뿐만 아니라 서로 데이터를 교환할 수 있는 경우 가능한 확장 중 하나입니다. 물론 이 작업은 마법사를 통해 수행할 수 있지만(데이터가 많은 경우 매우 느릴 수 있음) 클라우드 서버를 통해 직접 훨씬 더 효율적이고 빠르게 수행할 수 있습니다.
이것이 필요한 것입니다. 마스터의 중재 없이 한 에이전트에서 다른 에이전트로 데이터를 재귀적으로 전송하지만 마스터에 대한 결과 반환을 보장합니다. 저것들. 예를 들어 컴퓨터가 꺼져 있고 동시에 잠재적으로 효과적인 의사 결정 분기가 중단되었기 때문에 에이전트가 작업을 수행하고 완료하지 않고 작업을 중지한 것으로 판명되지 않도록 합니다.
예를 들어, 체스 게임을 분석하는 작업입니다. 마스터는 조각을 정렬하고 지금 움직여야 하는 조각의 색상에 대한 작업을 생성합니다. 하나의 그림 - 하나의 작업. 자신의 조각에 대한 작업을 받은 각 에이전트는 조각을 이동할 수 없을 때 추가 분석을 위해 약속되지 않은 옵션을 버리고 나머지 조각에서 새로운 배열을 형성하여 이미 상대방 조각에 대한 작업 형태로 더 이전됩니다. 등. 등. 검색 깊이를 체크메이트하거나 교착 상태로 만들거나 초과합니다.
이러한 작업이 클라우드의 현재 구현에 위임된 경우 전체 열거에 대한 작업 패키지를 구성하는 것만 가능합니다. 그리고 클라우드에는 이를 위한 에이전트가 충분하지 않으며 마스터가 이러한 모든 작업을 패키지로 분해하기에 충분한 메모리를 가질 가능성은 거의 없습니다. 유망하지 않은 옵션을 선별하는 메커니즘이 없기 때문입니다. 결국, 조각의 새로운 분석된 움직임이 있을 때마다 작업의 수는 기하급수적으로 증가하지만 전체 열거와 마찬가지로 그 중 상당 부분이 폐기되고 의미 없는 작업을 생성하지 않습니다. 그리고 의사 결정 트리의 특정 깊이 또는 너비로 다이빙한 후에만 전망에 대해 알 수 있습니다. 그리고 이 클라우드 구현의 깊이는 1과 같습니다. 마스터에서 에이전트로 또는 그 반대로.
내가 이 말을 하는 이유. 거래의 경우 유망하지 않은 분기를 잘라내는 재귀 검색의 구현도 필요합니다. 결국, 하나의 극값이 아니라 많은 지역 극값을 찾는 것이 좋습니다(정말 많이 있습니다). 또한 가능한 모든 옵션에 대한 검색 공간은 천문학적입니다. 분산 컴퓨팅의 모든 네트워크에서 가져온 에이전트로는 충분하지 않습니다. 이를 위해 각 단계에서 작업에서 얻은 포인트의 가장 가까운 이웃을 반복합니다(포인트 좌표 - Expert Advisor의 입력 매개변수 ). 현재와 비교하여 결과가 개선되었는지 여부. 그들 중 일부가 저하되거나 검색 깊이를 넘어서면 폐기하십시오. 개선되면 재귀적으로 더 살펴보고 개선된 지점에서 추가 작업 패키지를 구성하여 에이전트에게 배포합니다. 지역 극값을 찾은 경우(이웃의 모든 점이 현재 결과를 악화시킬 뿐입니다), 결과를 주 애플리케이션으로 반환합니다. 극한값을 찾은 후 마스터에게 전달한 다음 순방향 테스트로 분석합니다.
그러한 문제를 정면으로 해결하는 것은 불가능하기 때문에 옵션의 천문학적인 수. 유전 알고리즘은 또한 국소 극값을 찾지 않고(직접 가까운 전역 극값 근처에서 멈춥니다), 극한에 관계없이 중간 결과만 표시합니다. 유전 알고리즘과 철저한 검색은 제한적이고 이산적인 검색 공간을 가지고 있다는 사실은 말할 것도 없습니다. 그리고 필요한 것은 국부 극값의 최대 수를 검색하는 것입니다. 그러나 빠릅니다. 마스터에서 에이전트로, 에이전트에서 다른 에이전트로의 약속되지 않은 작업 세대를 차단하고 범위를 제한하지 않습니다. 클라우드가 재귀적 작업 전송을 구현했다면 문제가 해결되었을 것입니다.
클라우드 컴퓨팅에서 내 PC를 사용하려면
MQL5 클라우드 네트워크 . 하지만 여기 http://www.mql5.com 사이트의 내 계정에 에이전트가 표시되지 않는 문제가 있습니다. 즉, 내 PC 사용에 대한 수수료가 떨어지지 않습니다. MT5 MetaTrader 5 Agents Manager 자체에 내 계정 이름을 입력했습니다.
하지만 여기 http://www.mql5.com 사이트의 내 계정에 에이전트가 표시되지 않는 문제가 있습니다. 즉, 내 PC 사용에 대한 수수료가 떨어지지 않습니다. MT5 MetaTrader 5 Agents Manager 자체에 내 계정 이름을 입력했습니다.
따라서 문제 - 결제 네트워크의 기능을 향상시키기 위해 어떤 다른 기능이 포함되어야 합니까?
원격으로 호출할 수 있고 에이전트에서 값을 가져올 수 있는 클래스 메서드 : 원격 프로시저 호출(RPC). 이 같은:
물론 여기서 메소드 호출과 함께 이 메소드를 원격으로 호출하는 객체 필드의 현재 값을 에이전트에 전송해야 합니다.
결론은 클래스의 메인 인스턴스가 일종의 메소드를 호출하고 메소드 내부에 다른 클래스의 인스턴스가 생성되어 작업을 클라우드로 보내는 것입니다. 결과가 반환됩니다.
예를 들어, 작업은 체스에서 여러 움직임을 잘못 계산하는 형태로 생성됩니다. 원격으로 실행되는 메인 메소드에서는 한 번의 움직임에 대해 오산으로 다양한 조합이 생성되어 특정 클래스의 객체 형태로 발송됩니다. 이동이 결과로 끝나지 않았거나 계산 깊이가 한계를 초과하지 않은 경우 동일한 방법을 다시 호출합니다. 등. 등.
단말의 참여가 없어도 좋습니다.
누가 이 "에이전트 중 하나"에 대한 데이터를 생성합니까? 스크립트나 인디케이터가 이를 수행할 수 있습니까?
모든 에이전트가 나머지에 대한 초기 데이터를 생성할 수 있습니다. 전체 또는 선택된 에이전트에게 전송하거나 브로드캐스트할 수 있습니다.
모든 에이전트는 데이터 프레임을 다른 에이전트에 보낼 수 있습니다.
에이전트 간의 의사 소통이 필요한 이유는 가능하면 편협한 마음을 계몽하십시오.
이전 계산 의 데이터/결과를 교환 해야 하는 관련 문제를 해결합니다.
반드시 클라우드에 있는 것은 아닙니다. 로컬 영역에서 에이전트의 고속 네트워크를 만들고 대규모 데이터 교환으로 복잡한 작업을 시작할 수 있습니다.
그 결과 슈퍼컴퓨터 없이도 강력한 컴퓨터 네트워크를 구축할 수 있다.
아마도 원격으로 호출할 수 있고 에이전트로부터 값을 얻을 수 있는 클래스 메서드 일 것입니다. 이 같은:
물론 여기서 메소드 호출과 함께 이 메소드를 원격으로 호출하는 객체 필드의 현재 값을 에이전트에 전송해야 합니다.아니요, 데이터 프레임을 교환하는 유일한 실제 옵션이 있습니다. 기능의 원격 실행은 심각하지 않습니다. 올바른 마음을 가진 사람은 정보 환경을 복제할 수 없기 때문입니다.
프레임 작업의 일부로 기능을 확장할 수 있습니다.
정보를 위한 경우:
네트워크 지연 비용은 전체 프로세스를 최적화하기 위해 결과를 명시적으로 패키징하고 가능한 한 적은 데이터를 전송해야 하는 것과 같습니다. 예를 들어, 100,000,000 패스에 대해 빠르게 발생하는(1초 미만) 수학 문제가 있는 경우 최적화 프로세스를 즉시 1,000-10,000 패스의 부분으로 알고리즘 방식으로 배포하고 결과와 함께 그룹 처리 코드를 작성하는 것이 좋습니다. 일괄 반환됩니다. 이것은 네트워크에서 많은 시간이 소요되는 100,000,000회 반환에 비해 큰 이점을 제공합니다.
우리 쪽에서는 속사급 작업의 경우 각 에이전트에 수십 및 수백 개의 패스 발급과 응답 번들링을 함께 심각하게 지원합니다. 그 결과 네트워크 전송이 크게 절약되고 네트워크 대기 시간이 최소화됩니다.
아니요, 데이터 프레임을 교환하는 유일한 실제 옵션이 있습니다. 기능의 원격 실행은 심각하지 않습니다. 올바른 마음을 가진 사람은 정보 환경을 복제할 수 없기 때문입니다.
모든 작업에서 결과를 패키징할 수 있는 것은 아닙니다. 일부 응용 프로그램과 리소스 집약적 인 경우 결과가 유일한 것일 수도 있고 전혀 발견되지 않을 수도 있으며 실패한 작업은 재생 과정에서 폐기됩니다. 누락된 결과는 반환할 필요조차 없습니다.
그러면 다르게 할 수 있습니다. 즉, 주요 작업은 측면에서 작업을 생성하고 에이전트에게 이에 대해 알립니다. 그리고 에이전트는 작업과 함께 원격 메서드를 호출하고 계산하고 결과가 나오면 원격 메서드를 호출하여 결과를 반환합니다.
예를 들어, 문제: 페르마 수의 소수를 찾는 것. 결과가 전혀 없을 수도 있고, 하나 또는 여러 개일 수도 있습니다. 결론은 이러한 동일한 잠재적 제수를 열거하는 것은 매우 자원 집약적인 작업이라는 것입니다. 먼저 큰 수의 형태로 개체를 만들어야 합니다(작업에서 정보 전송 비용을 줄이기 위해 정수 형식으로 두 개의 숫자만 지정할 수 있습니다: 주와 가수). 그런 다음 단순성을 위해 이 숫자를 확인합니다(단순한 확인이 수행되어 숫자가 소수가 아닌 90% 이상임을 알 수 있음). 그런 다음 단순성 테스트가 성공적으로 통과되면 루프에서 모듈로를 제곱하여 조건의 일치를 찾습니다. 루프가 끝나기 전에 조건이 일치하지 않으면 결과가 없고 반환할 것이 없습니다. 이 경우 에이전트는 메인 애플리케이션에서 원격으로 적절한 메소드를 호출하여 원격으로 다음 작업을 요청해야 합니다. 결과를 찾으면 다른 메서드를 호출하고 동일한 결과를 전달해야 합니다.
저것들. 작업이 다르고 프레임 구조가 모든 사람에게 적합하지 않습니다. 그리고 위의 예에서 네트워크 지연 비용도 무시할 수 있습니다. 하나의 작업은 두 개의 정수를 에이전트에 전달하는 것으로 구성됩니다.
모든 작업을 패키징할 수 있는 것은 아닙니다. 일부 응용 프로그램과 리소스 집약적 인 경우 결과가 유일한 것일 수도 있고 전혀 발견되지 않을 수도 있으며 실패한 작업은 재생 과정에서 폐기됩니다. 누락된 결과 는 반환할 필요도 없습니다 .
프레임 구성표를 사용하는 경우 "서버 에이전트"에 빈 결과를 반환하지 않거나 단순히 "패킷 계산됨, 데이터 없음" 플래그를 반환합니다.
프레임 모드가 어떻게 작동하는지 아십니까? Expert Advisor의 헤드 부분은 터미널 창에서 직접 실행되어 원격 에이전트의 응답(데이터 프레임)을 기다립니다. 즉, 서버 부분은 차트에 앉아 데이터를 수신하고 무엇이든 시각화할 수 있습니다.
직접 읽고 사용해 보십시오: https://www.mql5.com/ru/code/914
프레임워크 체계를 사용하는 경우 "서버 에이전트"에 빈 결과를 반환하지 마십시오.
그래서 이것은 단지 기초입니다. 주요 작업과 계산에 리소스를 매우 많이 사용하는 작업은 재귀적입니다. 그리고 클라우드는 그러한 작업을 위한 것이 아닙니다. 그것은 철저한 열거를 위해서만 만들어집니다. 전체 열거는 많은 적용 문제에서 사용되지 않습니다. 그는 희망이 없습니다. 너비가 있는 깊이 우선 검색과 너비가 있는 깊이 우선 검색에는 재귀 작업이 필요합니다. 예를 들어, 분자의 합성. 저것들. 플레이 과정에서 잠재적인 솔루션 트리가 구축되며, 각 분기는 컴퓨팅 리소스를 많이 사용합니다. 그러나 모든 지점이 생산적인 것은 아닙니다. 저것들. 어딘가에서 검색이 중단되지만 동시에 깊이나 폭이 다른 잠재적인 분기에서 검색이 계속됩니다.
전체 열거는 실제로 사용되지 않습니다. 대부분의 적용된 문제의 경우 해결책을 찾는 데 시간이 충분하지 않습니다(예: 체스 게임의 움직임을 분석하는 문제). 그리고 유망하지 않은 의사결정 분기의 가지치기를 사용한 재귀적 방법은 특히 분산 컴퓨팅 에서 고속을 제공합니다. 따라서 응용 프로그램을 클라우드로 끌어들이려면 이 클라우드를 작업에 맞게 조정해야 하며, 모든 것을 포기하고 잠재 고객에 관계없이 모든 옵션을 연속적으로 정렬할 것이라고 생각해서는 안 됩니다. 기가플롭과 적은 수의 컴퓨터로 속도가 느리기는 하지만 분산 컴퓨팅의 자체 네트워크를 만드는 것이 더 쉬울 것입니다. 유망한 방향으로만 검색하고 Cloud Network보다 훨씬 빠르게 올바른 솔루션을 찾을 것입니다. 또한 많은 프로그래밍 언어에는 이를 위한 도구가 있습니다. 기성품 RPC 구현.
예를 들어, 페르마 수의 소수 제수에 대한 동일한 검색은 하위 문제로 나눌 수 있습니다. 기본 응용 프로그램은 작업을 생성합니다. 다음 계층은 객체를 만들고 나머지에서 빠른 우선 순위 검사를 수행하여 작업을 형성합니다. 다음 레이어는 조건을 찾습니다. 페르마 수의 제수를 찾거나 찾지 못함. 작업은 감지된 숫자로 다시 구성됩니다. 다음 계층은 소수에 대한 전체 검사를 수행하고 숫자가 소수가 아니면 작업을 생성합니다. 단순하면 결과를 기본 응용 프로그램에 반환합니다. 다음 층은 페르마 수의 소수가 아닌 약수를 인수분해하고 그로부터 이전 층에 대한 할당을 형성합니다.
에이전트가 각 계층에서 작업을 수행하는 컨베이어가 나타납니다. 그리고 결과를 찾을 수 있는지 여부는 갈퀴로 작성됩니다. 솔루션에 대한 추가 검색을 위해 분명히 유망하지 않은 숫자는 파이프라인에서 폐기하는 것이 중요합니다. 저것들. 많은 컴퓨팅 리소스가 절약되고 수천 명의 에이전트를 약속 없는 작업에 쌓아서 분쇄하려고 시도하지 않습니다.
그래서 이것은 단지 기초입니다. 주요 작업과 계산에 리소스를 매우 많이 사용하는 작업은 재귀적입니다. 그리고 클라우드는 그러한 작업을 위한 것이 아닙니다. 그것은 철저한 열거를 위해서만 만들어집니다. 전체 열거는 많은 적용 문제에서 사용되지 않습니다. 그는 희망이 없습니다. 너비가 있는 깊이 우선 검색과 너비가 있는 깊이 우선 검색에는 재귀 작업이 필요합니다. 예를 들어, 분자의 합성. 저것들. 플레이 과정에서 잠재적인 솔루션 트리가 구축되며, 각 분기는 컴퓨팅 리소스를 많이 사용합니다. 그러나 모든 지점이 생산적인 것은 아닙니다. 저것들. 어딘가에서 검색이 중단되지만 동시에 깊이나 폭이 다른 잠재적인 분기에서 검색이 계속됩니다.
1,000-10,000 패스의 배치를 실행하고 의미 있는 결과만 반환합니다. 이것은 매우 효율적인 알고리즘 기술입니다.
나는 위에서 이것에 대해 구체적으로 썼습니다.
전체 열거는 실제로 사용되지 않습니다. 대부분의 적용된 문제의 경우 해결책을 찾는 데 시간이 충분하지 않습니다(예: 체스 게임의 움직임을 분석하는 문제). 그리고 유망하지 않은 의사결정 분기의 가지치기를 사용하는 재귀적 방법은 특히 분산 컴퓨팅 에서 고속을 제공합니다. 따라서 응용 프로그램을 클라우드로 끌어들이려면 이 클라우드를 작업에 맞게 조정해야 하며 잠재 고객에 관계없이 모든 옵션을 삭제하고 모든 옵션을 연속적으로 정렬할 것이라고 생각해서는 안 됩니다. 기가플롭과 더 적은 수의 컴퓨터로 덜 빠르게 실행되지만 더 효율적이기 때문에 분산 컴퓨팅의 자체 네트워크를 만드는 것이 더 쉬울 것입니다. 유망한 방향으로만 검색하고 Cloud Network보다 훨씬 빠르게 올바른 솔루션을 찾을 것입니다. 또한 많은 프로그래밍 언어에는 이를 위한 도구가 있습니다. 기성품 RPC 구현.
예를 들어, 페르마 수의 소수 제수에 대한 동일한 검색은 하위 문제로 나눌 수 있습니다. 기본 응용 프로그램은 작업을 생성합니다. 다음 계층은 객체를 생성하고 나머지에서 빠른 우선 순위 검사를 수행하여 작업을 형성합니다. 다음 레이어는 조건을 찾습니다. 페르마 수의 제수를 찾거나 찾지 못함. 작업은 감지된 숫자로 다시 구성됩니다. 다음 계층은 소수에 대한 전체 검사를 수행하고 숫자가 소수가 아니면 작업을 생성합니다. 단순하면 결과를 기본 응용 프로그램에 반환합니다. 다음 층은 페르마 수의 소수가 아닌 제수를 인수분해하고 그로부터 이전 층에 대한 할당을 형성합니다.
데이터 교환 및 데모에 대해 위에서 읽으십시오.
마스터 프로세스가 추가 사용자 지정 데이터인 모든 에이전트에 데이터를 추가로 전송할 수 있도록 데이터 교환을 더욱 확장하는 것이 제안됩니다. 결과적으로 원격 에이전트에 새로운 사용자 지정 조건을 제공하는 부분만 고려할 수 있습니다. 결과적으로 적어도 문제의 조건을 변경할 때마다 원하는 대로 계산할 수 있습니다.
에이전트가 마스터로부터 작업을 수신할 수 있을 뿐만 아니라 서로 데이터를 교환할 수 있는 경우 가능한 확장 중 하나입니다. 물론 이 작업은 마법사를 통해 수행할 수 있지만(데이터가 많은 경우 매우 느릴 수 있음) 클라우드 서버를 통해 직접 훨씬 더 효율적이고 빠르게 수행할 수 있습니다.
Renat :
에이전트가 마스터로부터 작업을 수신할 수 있을 뿐만 아니라 서로 데이터를 교환할 수 있는 경우 가능한 확장 중 하나입니다. 물론 이 작업은 마법사를 통해 수행할 수 있지만(데이터가 많은 경우 매우 느릴 수 있음) 클라우드 서버를 통해 직접 훨씬 더 효율적이고 빠르게 수행할 수 있습니다.
이것이 필요한 것입니다. 마스터의 중재 없이 한 에이전트에서 다른 에이전트로 데이터를 재귀적으로 전송하지만 마스터에 대한 결과 반환을 보장합니다. 저것들. 예를 들어 컴퓨터가 꺼져 있고 동시에 잠재적으로 효과적인 의사 결정 분기가 중단되었기 때문에 에이전트가 작업을 수행하고 완료하지 않고 작업을 중지한 것으로 판명되지 않도록 합니다.
예를 들어, 체스 게임을 분석하는 작업입니다. 마스터는 조각을 정렬하고 지금 움직여야 하는 조각의 색상에 대한 작업을 생성합니다. 하나의 그림 - 하나의 작업. 자신의 조각에 대한 작업을 받은 각 에이전트는 조각을 이동할 수 없을 때 추가 분석을 위해 약속되지 않은 옵션을 버리고 나머지 조각에서 새로운 배열을 형성하여 이미 상대방 조각에 대한 작업 형태로 더 이전됩니다. 등. 등. 검색 깊이를 체크메이트하거나 교착 상태로 만들거나 초과합니다.
이러한 작업이 클라우드의 현재 구현에 위임된 경우 전체 열거에 대한 작업 패키지를 구성하는 것만 가능합니다. 그리고 클라우드에는 이를 위한 에이전트가 충분하지 않으며 마스터가 이러한 모든 작업을 패키지로 분해하기에 충분한 메모리를 가질 가능성은 거의 없습니다. 유망하지 않은 옵션을 선별하는 메커니즘이 없기 때문입니다. 결국, 조각의 새로운 분석된 움직임이 있을 때마다 작업의 수는 기하급수적으로 증가하지만 전체 열거와 마찬가지로 그 중 상당 부분이 폐기되고 의미 없는 작업을 생성하지 않습니다. 그리고 의사 결정 트리의 특정 깊이 또는 너비로 다이빙한 후에만 전망에 대해 알 수 있습니다. 그리고 이 클라우드 구현의 깊이는 1과 같습니다. 마스터에서 에이전트로 또는 그 반대로.
내가 이 말을 하는 이유. 거래의 경우 유망하지 않은 분기를 잘라내는 재귀 검색의 구현도 필요합니다. 결국, 하나의 극값이 아니라 많은 지역 극값을 찾는 것이 좋습니다(정말 많이 있습니다). 또한 가능한 모든 옵션에 대한 검색 공간은 천문학적입니다. 분산 컴퓨팅의 모든 네트워크에서 가져온 에이전트로는 충분하지 않습니다. 이를 위해 각 단계에서 작업에서 얻은 포인트의 가장 가까운 이웃을 반복합니다(포인트 좌표 - Expert Advisor의 입력 매개변수 ). 현재와 비교하여 결과가 개선되었는지 여부. 그들 중 일부가 저하되거나 검색 깊이를 넘어서면 폐기하십시오. 개선되면 재귀적으로 더 살펴보고 개선된 지점에서 추가 작업 패키지를 구성하여 에이전트에게 배포합니다. 지역 극값을 찾은 경우(이웃의 모든 점이 현재 결과를 악화시킬 뿐입니다), 결과를 주 애플리케이션으로 반환합니다. 극한값을 찾은 후 마스터에게 전달한 다음 순방향 테스트로 분석합니다.
그러한 문제를 정면으로 해결하는 것은 불가능하기 때문에 옵션의 천문학적인 수. 유전 알고리즘은 또한 국소 극값을 찾지 않고(직접 가까운 전역 극값 근처에서 멈춥니다), 극한에 관계없이 중간 결과만 표시합니다. 유전 알고리즘과 철저한 검색은 제한적이고 이산적인 검색 공간을 가지고 있다는 사실은 말할 것도 없습니다. 그리고 필요한 것은 국부 극값의 최대 수를 검색하는 것입니다. 그러나 빠릅니다. 마스터에서 에이전트로, 에이전트에서 다른 에이전트로의 약속되지 않은 작업 세대를 차단하고 범위를 제한하지 않습니다. 클라우드가 재귀적 작업 전송을 구현했다면 문제가 해결되었을 것입니다.