핵심은 수천 개의 if ... then ... else 문으로 구성되는 응용 프로그램 작성을 고려하고 있습니다. 응용 프로그램의 목적은 어떤 풍경에서 소가 어떻게 움직이는 지 예측할 수 있도록하는 것입니다. 그들은 태양, 바람, 음식 소스, 갑작스러운 사건 등과 같은 것들의 영향을받습니다.

그러한 응용 프로그램을 어떻게 관리 할 수 ​​있습니까? 수백 번의 IF 문 후에 프로그램이 어떻게 반응하고 특정 반응으로 이어지는지를 디버깅하는 것이 예측할 수 없을만큼 좋을 것이라고 생각합니다. 매번 IF 문 전체를 통과해야합니다.

규칙 엔진에 대해 조금 읽었지만 이러한 복잡성을 어떻게 해결할 수 있는지 알지 못합니다.

논리 프로그래밍 언어 인 프롤로그가 원하는 것일 수 있습니다. 귀하의 문제 진술은 그것이 적합한 지 여부를 평가하기에 충분하지는 않지만 귀하의 의견과 비슷합니다.

프롤로그 프로그램은 적용되는 사실과 규칙으로 구성됩니다. 다음은 "소가 배가 고프고 새 위치에 기존 위치보다 더 많은 음식이있는 경우 암소가 위치로 이동합니다"라는 간단한 규칙 예입니다.

moves_to(Cow, Location) :-
  hungry(Cow),
  current_location(Cow, OldLoc),
  food_in(OldLoc, OldFood), food_in(Location, NewFood),
  NewFood > OldFood.

대문자로 된 모든 것은 변수이며 가치를 모르는 것입니다. 프롤로그는 모든 조건을 만족시키는 이러한 변수의 값을 찾으려고 시도합니다. 이 프로세스는 Prolog 및 유사한 논리 프로그래밍 환경의 핵심 인 통합이라는 강력한 알고리즘으로 수행됩니다.

규칙 외에도 사실 데이터베이스가 제공됩니다. 위의 규칙으로 작동하는 간단한 예는 다음과 같습니다.

current_location(white_cow, pasture).

current_location(black_cow, barn).
hungry(black_cow).

current_location(angry_bull, forest).
hungry(angry_bull).

food_in(barn, 3).
food_in(pasture, 5).
food_in(forest, 1).

white_cow 및 목초지 등은 대문자로 작성되지 않았습니다. 그것들은 변수가 아니라 원자입니다.

마지막으로 질문을하고 무슨 일이 일어날 지 물어 봅니다.

?- moves_to(white_cow, Destination).
No.
?- moves_to(black_cow, Destination).
Destination = pasture
?- moves_to(Cow, Destination).
Cow = black_cow, Destination = pasture
Cow = angry_bull, Destination = barn
Cow = angry_bull, Destination = pasture

첫 번째 질문은 흰 암소가 어디로 움직일지를 묻습니다. 위의 규칙과 사실을 감안할 때 대답은 아니오입니다. 이것은 원하는 것에 따라 "모름"또는 "움직이지 않습니다"로 해석 될 수 있습니다.

두 번째 쿼리는 검은 암소의 이동 위치를 묻습니다. 먹기 위해 목초지로 옮깁니다.

마지막 질문은 모든 소가 어디로 이동하는지 묻습니다. 결과적으로 모든 가능한 (Cow, Destination) 말이 이해됩니다. 이 경우 검은 황소는 예상대로 목초지로 이동합니다. 그러나 화난 황소는 규칙을 만족시키는 두 가지 선택이 있습니다. 목초지 나 헛간으로 이동할 수 있습니다.

참고 : 마지막으로 Prolog를 작성한 지 몇 년이 지났지 만 모든 예제가 구문 적으로 유효하지는 않지만 아이디어는 정확해야합니다.

태클 경우 웹 문제 당신은 각각의 특정 규칙이 독립적으로 코딩 규칙 엔진을 만들 수 있습니다. 이에 대한 추가 개선 사항은 규칙을 작성하기 위해 DSL (Domain Specific Language)을 작성하는 것이지만 DSL만으로는 문제를 한 코드 기반 (기본)에서 다른 (DSL)로 대체 할뿐입니다. 구조가 없으면 DSL은 모국어 (Java, C # 등)보다 나아지지 않으므로 개선 된 구조적 접근 방식을 찾은 후 다시 돌아올 것입니다.

근본적인 문제는 모델링 문제가 있다는 것입니다. 이와 같은 조합 상황이 발생할 때마다 상황을 설명하는 모델 추상화가 너무 거칠다는 것이 명백합니다. 단일 엔터티에서 다른 모델에 속하는 요소를 결합 할 가능성이 높습니다.

모델을 계속 분류하면 결국이 조합 효과가 완전히 사라집니다. 그러나이 경로를 취할 때 더 큰 혼란을 일으키는 디자인에서 길을 잃기 쉽습니다. 여기에서 완벽주의는 반드시 친구가 아닙니다.

유한 상태 머신과 룰 엔진은이 문제를 어떻게 분석하고보다 관리하기 쉽게 만드는지 보여주는 예일뿐입니다. 여기서의 주요 아이디어는 이와 같은 조합 문제를 제거하는 좋은 방법은 종종 디자인 을 만들고 시스템이 만족스럽게 수행 될 때까지 중첩 된 추상화 수준으로 광고 구역을 반복하는 것 입니다. 복잡한 패턴을 만드는 데 프랙탈이 사용되는 방식과 유사합니다. 현미경을 사용하거나 높은 조감도에서 시스템을 보더라도 규칙은 동일하게 유지됩니다.

이것을 도메인에 적용하는 예입니다.

소가 지형을 통해 어떻게 움직이는 지 모델링하려고합니다. 귀하의 질문에 세부 사항이 없지만 많은 양의 if에 결정 조각이 포함되어 if cow.isStanding then cow.canRun = true있지만 예를 들어 지형의 세부 정보를 추가하면 혼란에 빠질 것입니다. 따라서 수행하려는 모든 작업에 대해 생각할 수있는 모든 측면을 확인하고 다음 가능한 작업에 대해 이러한 확인을 반복해야합니다.

먼저 반복 가능한 설계가 필요합니다.이 경우 시뮬레이션의 변화하는 상태를 모델링하는 FSM이됩니다. 따라서 가장 먼저 할 일은 상태 인터페이스, 전환 인터페이스 및 전환 컨텍스트를 정의하는 참조 FSM을 구현하는 것입니다.다른 두 사람이 사용할 수있는 공유 정보를 포함 할 수 있습니다. 기본 FSM 구현은 컨텍스트에 관계없이 한 전환에서 다른 전환으로 전환합니다. 여기에서 규칙 엔진이 시작됩니다. 규칙 엔진은 전환이 발생하는 경우 충족해야하는 조건을 깨끗하게 캡슐화합니다. 여기서 규칙 엔진은 각각 부울을 리턴하는 평가 함수가있는 규칙 목록만큼 간단 할 수 있습니다. 전환이 이루어져야하는지 확인하려면 규칙 목록을 반복하고 규칙 중 하나라도 거짓으로 평가되면 전환이 발생하지 않습니다. 전환 자체에는 FSM의 현재 상태 (및 기타 가능한 작업)를 수정 하는 동작 코드 가 포함됩니다 .

이제 GOD 수준에서 단일 대형 FSM으로 시뮬레이션을 구현하기 시작하면 가능한 많은 상태, 전환 등이 발생합니다. if-else 엉망은 고정 된 것처럼 보이지만 실제로는 주변에 퍼져 있습니다. 이제 컨텍스트의 특정 정보에 대해 테스트를 수행하는 규칙 (이 시점에서 거의 모든 것을 포함)과 각 IF 본문은 전환 코드 어딘가에 있습니다.

프랙탈 분석을 입력하십시오. 첫 번째 단계는 각 젖소에 대해 FSM을 생성하는 것입니다. 여기서 젖소의 내부 상태 (서기, 달리기, 걷기, 방목 등)는 환경에 의해 영향을받습니다. 그래프가 완전하지 않을 수 있습니다. 예를 들어 방목은 스탠딩 상태에서만 액세스 할 수 있으며 다른 전이는 모델이 없기 때문에 해체됩니다. 여기서 소와 지형의 두 가지 모델로 데이터를 효과적으로 분리합니다. 각각 자체 속성이 설정되어 있습니다. 이 분석을 통해 전체 엔진 설계를 단순화 할 수 있습니다. 이제는 매우 구체적인 세부 사항을 결정하는 여러 개의 더 간단한 규칙 엔진 (각 전환마다 하나씩)을 결정하는 단일 규칙 엔진을 갖지 않습니다.

FSM에 동일한 코드를 다시 사용하기 때문에 기본적으로 FSM의 구성입니다. DSL을 더 일찍 언급했을 때를 기억하십니까? 당신이 쓸 규칙과 트랜지션이 많으면 DSL이 많은 일을 할 수있는 곳입니다.

더 깊어지다

이제 GOD는 더 이상 젖소의 내부 상태 관리에 대한 모든 복잡성을 처리하지 않아도되지만 더 나아가 야합니다. 예를 들어 지형 관리와 관련하여 여전히 많은 복잡성이 있습니다. 여기에서 고장이 충분한 곳을 결정합니다. 예를 들어 GOD에서 지형 역학 (긴 잔디, 진흙, 마른 진흙, 짧은 잔디 등)을 관리하게되면 동일한 패턴을 반복 할 수 있습니다. 모든 지형 상태 (긴 잔디, 짧은 잔디, 진흙, 건조 등)를 상태와 간단한 규칙 사이의 전환으로 새로운 지형 FSM으로 추출하여 지형 자체에 이러한 논리를 포함시키는 것을 막을 방법은 없습니다. 예를 들어, 진흙 상태에 도달하려면 규칙 엔진이 컨텍스트를 확인하여 액체를 찾으십시오. 그렇지 않으면 불가능합니다. 이제 하나님은 여전히 ​​단순 해졌습니다.

FSM을 자율적으로 만들어 각 스레드를 제공하여 FSM 시스템을 완성 할 수 있습니다. 이 마지막 단계는 필요하지 않지만 의사 결정을 위임하는 방법 (전문 FSM을 시작하거나 미리 결정된 상태 만 반환)을 조정하여 시스템의 상호 작용을 동적으로 변경할 수 있습니다.

전환이 "다른 가능한 작업"을 수행 할 수 있다고 언급 한 것을 기억하십니까? 서로 다른 모델 (FSM)이 서로 통신 할 수있는 가능성을 추가하여이를 살펴 보겠습니다. 일련의 이벤트를 정의하고 각 FSM이 이러한 이벤트에 대한 리스너를 등록하도록 허용 할 수 있습니다. 따라서, 예를 들어 암소가 지형 헥스에 들어가면 헥스는 전이 변경을 위해 리스너를 등록 할 수 있습니다. 여기서는 각 FSM이 특정 도메인에 대한 지식없이 매우 높은 수준으로 구현되므로 약간 까다로워집니다. 그러나 암소가 이벤트 목록을 게시하도록하여이를 달성 할 수 있으며 셀이 반응 할 수있는 이벤트를 볼 경우 셀을 등록 할 수 있습니다. 여기서 좋은 이벤트 계층 구조는 좋은 투자입니다.

지형 패치 자체 모델에 포함 된 잔디 FSM과 함께 잔디의 영양 수준과 성장주기를 모델링하여 더 깊이 밀어 넣을 수 있습니다.

모든 측면이 거의 자체적으로 관리되므로 더 경건한 일에 시간을 할애 할 수 있기 때문에 GOD가 할 일이 거의 없을 정도로 아이디어를 추진할 수 있습니다.

요약

위에서 언급했듯이 여기 FSM은 해결책이 아니며, 그러한 문제에 대한 해결책이 코드 당 발견되지 않고 문제를 모델링하는 방법을 설명하는 수단 일뿐입니다. FSM 제안보다 가능하고 훨씬 나은 다른 솔루션이있을 가능성이 큽니다. 그러나 "프랙탈"접근 방식은이 난이도를 관리하는 좋은 방법으로 남아 있습니다. 올바르게 수행하면 중요한 곳에 더 깊은 레벨을 동적으로 할당하는 동시에 중요도가 낮은 곳에 더 간단한 모델을 제공 할 수 있습니다. 자원을 사용할 수있게되면 변경 사항을 대기시키고 적용 할 수 있습니다. 행동 순서에서 소에서 풀 패치로의 영양소 이동을 계산하는 것이 중요하지 않을 수 있습니다. 그러나 이러한 전환을 기록하고 나중에 변경 사항을 적용하거나 단순히 규칙 엔진을 교체하거나 FSM 구현을 직접 필드에없는 요소에 대해 더 단순한 순진 버전으로 대체하여 교육받은 추측에 근사 할 수 있습니다. 더 자세한 상호 작용을 통해 초점과 더 많은 리소스를 확보 할 수 있습니다. 이 모든 것이 시스템 전체를 다시 방문하지 않고; 각 부품이 잘 격리되어 있기 때문에 드롭 인 교체를 작성하거나 모델 깊이를 확장하기가 더 쉬워집니다. 표준 설계를 사용하면이를 기반으로 DSL과 같은 임시 도구에 대한 투자를 극대화하여 규칙이나 이벤트에 대한 표준 어휘를 정의하고 다시 높은 수준에서 시작하여 필요에 따라 세분화를 추가 할 수 있습니다. 각 부품이 잘 격리되어 있기 때문에 드롭 인 교체를 작성하거나 모델 깊이를 확장하기가 더 쉬워집니다. 표준 설계를 사용하면이를 기반으로 DSL과 같은 임시 도구에 대한 투자를 극대화하여 규칙이나 이벤트에 대한 표준 어휘를 정의하고 다시 높은 수준에서 시작하여 필요에 따라 세분화를 추가 할 수 있습니다. 각 부품이 잘 격리되어 있기 때문에 드롭 인 교체를 작성하거나 모델 깊이를 확장하기가 더 쉬워집니다. 표준 설계를 사용하면이를 기반으로 DSL과 같은 임시 도구에 대한 투자를 극대화하여 규칙이나 이벤트에 대한 표준 어휘를 정의하고 다시 높은 수준에서 시작하여 필요에 따라 세분화를 추가 할 수 있습니다.

코드 예제를 제공하지만 지금 당장 할 수있는 전부입니다.

당신이 이야기하는 모든 조건문은 실제로 프로그램 자체의 일부가 아닌 프로그램을 구성하는 데이터 여야합니다. 이러한 방식으로 처리 할 수 ​​있으면 코드를 수정하고 모델을 개선 할 때마다 다시 컴파일하지 않고 구성을 변경하여 프로그램 작동 방식을 자유롭게 수정할 수 있습니다.

문제의 성격에 따라 실제 세계를 모델링하는 방법에는 여러 가지가 있습니다. 다양한 조건이 시뮬레이션에 적용되는 규칙 또는 구속 조건이 될 수 있습니다. 다음과 같은 코드를 사용하는 대신 :

if (sunLevel > 0.75) {
   foreach(cow in cows) {
       cow.desireForShade += 0.5;
   }
}
if (precipitation > 0.2) {
   foreach(cow in cows) {
       cow.desireForShelter += 0.8;
   }
}

대신 다음과 같은 코드를 사용할 수 있습니다.

foreach(rule in rules) {
   foreach (cow in cows) {
      cow.apply(rule);
   }
}

또는 다수의 입력이 주어지면 소의 행동을 모델링하는 선형 프로그램을 개발할 수 있다면 각 구속 조건은 방정식 시스템에서 선이 될 수 있습니다. 그런 다음 반복 할 수있는 Markov 모델로 전환 할 수 있습니다.

상황에 맞는 올바른 접근 방식을 말하기는 어렵지만 제약 조건이 코드가 아닌 프로그램에 대한 입력으로 간주되면 훨씬 쉬운 시간을 가질 수 있다고 생각합니다.

아무도 이것을 언급하지 않았으므로 명시 적으로 말할 것이라고 생각했습니다.

"If .. Then .. Else"규칙의 수천은 잘못 설계된 응용 프로그램의 표시입니다.

도메인 별 데이터 표현은 이러한 규칙과 비슷할 수 있지만 구현시 도메인 별 표현과 유사해야한다고 확신하십니까?

작업에 적합한 소프트웨어 / 컴퓨터 언어를 사용하십시오. Matlab 은 문자 그대로 수천 개의 조건을 가질 수있는 복잡한 시스템을 모델링하는 데 자주 사용됩니다. if / then / else 절을 ​​사용하지 않고 수치 분석. R 은 오픈 소스 컴퓨터 언어로 도구와 패키지로 채워져 있습니다. 그러나 이는 모델을보다 수학적 용어로 다시 표현해야하므로 주요 영향과 모델 간 영향 간의 상호 작용을 모두 포함 할 수 있습니다.

아직 모델링하지 않았다면 모델링 및 시뮬레이션에 대한 과정을 따르십시오. 마지막으로해야 할 일은 if-then-else와 같은 모델을 작성하는 것입니다. 우리는 몬테 카를로 마르코프 체인, 지원 벡터 머신, 신경망, 잠재 변수 분석 등을 보유하고 있습니다. 사용 가능한 모델링 툴에 대한 부를 무시하여 100 년 동안 자신을 버리지 마십시오.

규칙 엔진은 많은 if / then 규칙이있는 경우 프로그래밍 언어를 몰라도 사용자가 규칙을 편집 할 수있는 프로그램 외부의 한 곳에서 규칙을 가져 오는 것이 도움이 될 수 있기 때문에 도움이 될 수 있습니다. 또한 시각화 도구를 사용할 수 있습니다.

논리 프로그래밍 솔루션 (예 : Prolog)도 볼 수 있습니다. if / then 문의 목록을 신속하게 수정하고 입력 조합이 특정 결과로 이어질지 여부 등의 작업을 수행 할 수 있습니다. 또한 프로 시저 코드보다 (또는 객체 지향 코드).

그것은 갑자기 나에게 떠올랐다.

의사 결정 학습 트리 (ID3 알고리즘) 를 사용해야합니다 .

누군가 귀하의 언어로 구현했을 가능성이 큽니다. 그렇지 않은 경우 기존 라이브러리를 이식 ​​할 수 있습니다

이것은 커뮤니티 위키 답변이며, 다른 답변에서 제안한 다양한 모델링 도구를 모은 것입니다. 리소스에 대한 링크를 추가했습니다.

수천 개의 하드 코딩 된 if / else 문에 대해 다른 접근 방식을 사용해야한다고 다시 언급 할 필요는 없다고 생각합니다.

• DSL 프로그래밍 (도메인 특정 언어)
• 마르코프 모델 / 마르코프 결정 프로세스
• Rete net / Rete 알고리즘
• 전문가 시스템
• Matlab , (Wikipedia)
• 아르 자형

모든 대규모 응용 프로그램에는 if-then-else다른 흐름 제어를 계산하지 않고 수천 개의 문이 포함되어 있으며 이러한 응용 프로그램은 복잡성에도 불구하고 여전히 디버깅 및 유지 관리됩니다.

또한, 명령문 수는 플로우를 예측할 수 없게하지 않습니다 . 비동기 프로그래밍이 수행합니다. 결정 론적 알고리즘을 동기식으로 사용하면 매번 100 % 예측 가능한 동작이 발생합니다.

사람들이 사용할 정확한 리팩토링 기술 을 제안 할 수 있도록 스택 오버플로 또는 코드 검토 에서 수행하려는 작업을 더 잘 설명 해야 합니다. "너무 많은 문장을 중첩시키지 않으려면 어떻게해야합니까?"와 같이보다 정확한 질문을하고 싶을 수도 있습니다 . if

응용 프로그램을 잘 설계하여 관리 할 수있게하십시오. 다양한 비즈니스 로직을 개별 클래스 / 모듈로 분할하여 애플리케이션을 설계하십시오. 이러한 각 클래스 / 모듈을 개별적으로 테스트하는 단위 테스트를 작성하십시오. 이는 중요하며 비즈니스 로직이 예상대로 구현되도록하는 데 도움이됩니다.

문제에서 벗어날 길을 설계하는 유일한 방법은 없지만, if 문을 작성하고 솔루션을 적용하는 다른 영역을 분리하려고 시도하면 복잡한 부분을 하나씩 관리 할 수 ​​있습니다. 그 작은 문제들 각각에.

리팩토링 에서 언급 한 규칙과 같은 기술을 사용하여 큰 조건을 관리 가능한 청크로 나눌 수 있습니다. 예를 들어 공통 인터페이스가있는 여러 클래스가 사례 설명을 대체 할 수 있습니다.

일찍 나가는 것도 큰 도움입니다. 오류 조건이있는 경우 예외를 발생 시키거나 중첩시키지 않고 리턴하여 함수 시작시 방해가되지 않도록하십시오.

조건을 술어 함수로 나누면 조건을 추적하는 것이 더 쉬울 수 있습니다. 또한 표준 형식으로 가져올 수 있다면 하드 코딩 된 형식 대신 동적으로 작성된 데이터 구조로 가져올 수 있습니다.

규칙 엔진을 사용하는 것이 좋습니다. Java의 경우 jBPM 또는 Oracle BPM이 유용 할 수 있습니다. 규칙 엔진을 사용하면 XML을 통해 응용 프로그램을 구성 할 수 있습니다.

이 문제는 "if-then"절차 코드 또는 비즈니스 애플리케이션을 위해 고안된 수많은 규칙 솔루션으로 설명 되든 "규칙"으로 잘 해결되지 않습니다. 머신 러닝은 이러한 시나리오를 모델링하기위한 많은 메커니즘을 제공합니다.

근본적으로, "체계"(즉, 목초지의 소)에 영향을 미치는 요인 (예를 들어, 태양, 바람, 음식 공급원, 갑작스런 사건 등)을 묘사하기위한 몇 가지 체계를 공식화해야한다. 불연속과 달리 실제 가치 기능적 표현을 만들 수 있다는 잘못된 생각에도 불구하고 실제 세계의 컴퓨터 (인간 신경계 포함)는 실제 가치를 기반으로하거나 실제 가치를 기반으로 계산하지 않습니다.

관련 요인에 대한 수치 표현이 있으면 여러 가지 수학적 모델을 구성 할 수 있습니다. 하나의 노드 세트가 젖소를 나타내고 다른 하나는 목초지의 일부 단위 영역을 나타내는 이분 그래프를 제안합니다. 어느 경우 에나 젖소는 목초지의 일부 지역을 차지합니다. 각각의 젖소에 대해 현재 및 모든 다른 목초지 단위와 관련된 실용 가치가 존재합니다. 이 모델이 젖소가 목장 단위의 실용 가치를 최적화하기 위해 (어떤 수단 으로든 젖소를) 추구한다고 가정하면, 젖소는 최적화를 위해 단위에서 단위로 이동합니다.

셀룰러 자동화는 모델 실행에 적합합니다. 실제 가치가있는 수학 세계에서 동기를 부여하는 소 운동의 기본 수학은 필드 그래디언트 모델입니다. 젖소들은 낮은 실용 가치의 위치에서 높은 실효 가치의 위치로 이동합니다.

시스템에 환경 변화를 주입하면 젖소 위치 설정의 정상 상태 솔루션으로 이동하지 않습니다. 또한 게임 이론의 측면을 적용 할 수있는 모델이 될 것입니다. 그러한 경우가 반드시이 경우에 많은 것을 추가하지는 않습니다.

이 모델의 장점은 모델이 실행되는 동안 도축 소 또는 "소"세포를 이분 그래프에 빼서 추가하여 쉽게 관리 할 수 ​​있다는 점입니다.

나는 많은 if-else 문을 정의해야한다고 생각하지 않습니다. 내 관점에서 볼 때 문제에는 여러 구성 요소가 있습니다.

• 성격, 구성이 다른 여러 개의 젖소가 있기 때문에 비동기 또는 멀티 스레드 여야합니다. 각각의 젖소는 다음 이동 전에 어느 방향으로 가야하는지 스스로에게 묻습니다. 내 생각에 동기화 코드는이 문제에 대한 나쁜 도구입니다.

• 의사 결정 트리의 구성은 지속적으로 변경됩니다. 실제 소의 위치, 날씨, 시간, 지형 등에 따라 다릅니다. 복잡한 if-else 나무를 만드는 대신 바람 장미 또는 방향-무게 함수로 문제를 줄여야한다고 생각 합니다. : 그림 1-일부 규칙의 방향-가중치 기능

  젖소는 항상 총 중량이 가장 큰 방향으로 가야합니다. 따라서 큰 의사 결정 트리를 작성하는 대신 각 소에 다른 방향-가중치 기능을 가진 규칙 세트를 추가하고 방향을 요청할 때마다 결과를 간단히 처리 할 수 ​​있습니다. 모든 위치 변경 또는 시간이 지남에 따라 이러한 규칙을 재구성하거나 이러한 세부 정보를 매개 변수로 추가하면 모든 규칙에 도달 할 수 있습니다. 구현 결정입니다. 방향을 얻는 가장 간단한 방법은 1 ° 간격으로 0 °에서 360 °까지 간단한 루프를 추가하는 것입니다. 그런 다음 각 360 방향의 합계 가중치를 계산하고 max () 함수를 통해 올바른 방향을 얻을 수 있습니다.

• 이를 위해서는 신경망이 반드시 필요하지는 않습니다. 각 규칙마다 하나의 클래스, 소에 대한 클래스, 지형에 대한 클래스, 시나리오에 대한 클래스 (예 : 규칙이 다른 3 마리의 소) 특정 지형 1 개). 그림 2-암소 앱 비동기 결정 노드 및 연결

  • 메시징 방향의 경우 빨간색-규칙을 통한 가중치 맵
  • 의사 결정 후 방향 및 위치 업데이트를위한 파란색
  • 방향 및 위치 업데이트 후 입력 업데이트의 경우 녹색
  • 입력을 받기위한 검은 색

  참고 : 아마도 이와 같은 것을 구현하기 위해 메시징 프레임 워크가 필요할 것입니다.

  따라서 학습 젖소를 만드는 것이 문제의 일부가 아닌 경우 신경망이나 유전자 알고리즘이 필요하지 않습니다. 나는 AI 전문가는 아니지만, 젖소를 실제 젖소에 적응 시키려면 유전자 알고리즘과 적절한 규칙을 사용하여 간단하게 할 수 있다고 생각합니다. 잘 이해하면 임의의 규칙 설정을 가진 소가 필요합니다. 그런 다음 실제 소의 동작을 모델 인구의 동작과 비교하고 실제 소와 가장 가까운 경로를 걷는 10 %를 유지할 수 있습니다. 그 후 유지 한 10 %를 기준으로 젖소 공장에 새로운 규칙 구성 제약 조건을 추가하고 모집단에 새로운 무작위 젖소를 추가하는 등 실제 젖소처럼 행동하는 모델 젖소를 얻을 수 있습니다.

나는 만약 당신이 진실로 수천 개의 IF ... THEN 규칙을 가지고 있다면 당신 이 과도하게 지정하고 있을지도 모른다고 덧붙였다. 가치있는 것을 위해, 내가 참석 한 신경망 모델링 대화는 종종 "단순한 규칙 세트"를 사용하여 상당히 복잡하고 합리적으로 실제 일치하는 동작 (이 경우 실제 뉴런)을 생성 할 수있는 방법을 설명하는 것으로 시작합니다. 그러니 확실해수천 개의 조건이 필요하십니까? 내 말은 날씨, 식량 원의 위치, 갑작스러운 사건, 방목, 지형의 4 ~ 5 가지 측면 외에도 실제로 더 많은 변수가 있습니까? 물론, 이러한 조건을 결합하여 가능한 모든 순열을 시도하면 수천 가지 규칙을 쉽게 가질 수 있지만 올바른 방법은 아닙니다. 어쩌면 다양한 요소들이 각 소의 위치에 편향을 가져 와서 전체 결정과 결합되는 퍼지 논리 스타일 접근 방식을 사용하면 훨씬 적은 수의 규칙으로이를 수행 할 수 있습니다.

또한 규칙 세트는 일반적인 코드 흐름과 분리되어야하므로 프로그램을 변경하지 않고도 규칙을 쉽게 조정할 수 있다는 점에 동의합니다. 경쟁 규칙 세트를 생각해 내고 실제 젖소 이동 데이터에 대한 규칙 세트를 확인할 수도 있습니다. 재미 있겠다.

인공 지능 분야 인 전문가 시스템이 언급되었습니다. 이것에 대해 조금 확장하려면 추론 엔진을 읽으면 도움이 될 수 있습니다. Google 검색이 더 유용 할 수 있습니다. DSL을 작성하는 것은 쉬운 일입니다. Gold Parser와 같은 파서를 사용하여 간단히 할 수 있습니다. 어려운 부분은 의사 결정 트리를 구축하고 효율적으로 실행하는 데 있습니다.

영국의 NHS Direct 웹 사이트 와 같은 많은 의료 시스템에서 이미 이러한 엔진을 사용하고 있습니다 .

.NET'er라면 Infer.NET 이 유용 할 것입니다.

젖소의 움직임을보고 있기 때문에 젖소는 360도 방향으로 붙어 있습니다 (소는 날 수 없습니다). 또한 여행 속도도 있습니다. 이것은 벡터로 정의 될 수 있습니다.

이제 태양의 위치, 언덕의 경사, 큰 소음과 같은 것들을 어떻게 처리합니까?

각 각도는 그 방향으로 가고자하는 욕구를 나타내는 변수 일 것입니다. 나뭇 가지가 90도에서 암소의 오른쪽에 찰칵 소리를냅니다 (소가 0 도라고 가정). 오른쪽으로 가고자하는 욕구가 줄어들고 270 (왼쪽)으로 가고자하는 욕구가 높아질 것입니다. 한 방향으로 가고자하는 소에 대한 영향을 더하거나 빼는 모든 자극을 겪습니다. 모든 자극이 적용되면 젖소는 가장 높은 방향으로 갈 것입니다.

자극이 이진일 필요가 없도록 그래디언트를 적용 할 수도 있습니다. 예를 들어 언덕은 한 방향으로 똑바로 있지 않습니다. 어쩌면 젖소는 계곡에 있거나 언덕 위의 도로에 평평하게 똑바로 있었고, 45 * 약간 언덕 위로 90 * 약간 언덕 아래에있었습니다. 180 * 가파른 언덕에서.

그런 다음 이벤트의 가중치와 조정 방향을 조정할 수 있습니다. 그런 다음 if then 목록을 통해 최대 값을 찾는 테스트가 하나 있습니다. 또한 자극을 추가하고 싶을 때 테스트 전에 적용 할 수 있으며 더 많은 복잡성을 추가 할 필요가 없습니다.

오히려 젖소가 360 방향으로 갈 것이라고 말하면 젖소를 36 방향으로 나눌 수 있습니다. 각각 10도

오히려 젖소가 360 방향으로 갈 것이라고 말하면 젖소를 36 방향으로 나눌 수 있습니다. 각각 10 도입니다. 얼마나 구체적이어야하는지에 따라.

OOP를 사용하십시오. 기본 조건을 처리하고 임의의 메소드를 실행하여 수행중인 작업을 시뮬레이션하는 클래스를 작성하는 방법은 어떻습니까?

프로그래머에게 도움을 요청하십시오.

class COW_METHODS {

    Function = array('Action1','Action2',....'ActionX');

    function doAction() {
       execute(Function[random(1,5000]);
    }

    function execute(DynamicFunction) {
        exec(DynamicFunction());
    }

    Function Action1() {
        turnRight();
        eatGrass();
    }
    /*  keep adding functions for COW Methods ...  etc  */
    /*  and add classes for conditions inherit them as needed  */
    /*  keep an object to define conditions =  Singleton etc.  */
}