Я розглядаю можливість створення програми, яка, за своєю суттю, складалася б із тисяч, якби ... тоді ... інших тверджень. Метою програми є можливість передбачити, як корі рухаються в будь-якому ландшафті. На них впливають такі речі, як сонце, вітер, джерело їжі, раптові події тощо.

Як можна керувати такою програмою? Я думаю, що після декількох сотень тверджень IF, це було б так само добре, як непередбачувано, як програма реагуватиме, і налагодження того, що призводить до певної реакції, означатиме, що потрібно буде кожного разу переходити все дерево IF-висловлювань.

Я читав трохи про правила двигунів, але не бачу, як вони обійшли б цю складність.

Мова логічного програмування Prolog може бути те, що ви шукаєте. Твоя постановка проблеми недостатньо конкретна, щоб я міг оцінити, чи підходить вона, але вона схожа на те, що ти кажеш.

Програма Prolog складається з застосованих фактів та правил. Ось просте приклад правило, яке говорить: "Корова рухається до місця, якщо корова голодна, і в новому місці є більше їжі, ніж у старому":

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

Усі речі великими літерами є змінними, речі, яким ви не знаєте значення. Пролог намагається знайти значення для цих змінних, які б задовольняли всі умови. Цей процес виконується за допомогою потужного алгоритму, який називається уніфікацією, що є серцем Пролога та подібних середовищ логічного програмування.

Окрім правил, надається база даних фактів. Простий приклад, який працює з правилами вище, може бути на кшталт:

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).

Зауважте, що біла корівка та пасовище тощо не пишеться великими літерами. Вони не є змінними, вони є атомами.

Нарешті ви робите запит і запитуєте, що буде.

?- 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

Перший запит запитує, куди рухатиметься біла корова. Враховуючи вищезазначені правила та факти, відповідь - ні. Це можна трактувати як "я не знаю" або "воно не рухається" залежно від того, що ви хочете.

Другий запит запитує, куди рухається чорна корова. Він переходить на пасовище, щоб поїсти.

Заключний запит запитує, куди рухаються всі корови. В результаті ви отримуєте все можливе (Корова, призначення), які мають сенс. У цьому випадку чорний бик рухається на пасовище, як очікувалося. Однак у розлюченого бика є два варіанти, які відповідають правилам, він може або переїхати на пасовище, або у сарай.

Примітка. Минуло роки, як я востаннє писав Prolog, всі приклади можуть бути не синтаксично дійсними, але ідея повинна бути правильною.

Вирішуючи проблему, якщо веб, ви можете створити двигун правил, де кожне конкретне правило кодується незалежно. Наступним уточненням цього було б створення мови для домену (DSL) для створення правил, однак лише DSL зміщує проблему з однієї бази коду (основної) на іншу (DSL). Без структури DSL не обійдеться нічим кращим, ніж рідна мова (Java, C # тощо), тому ми повернемося до неї після того, як знайдемо вдосконалений структурний підхід.

Основоположним питанням є те, що у вас виникає проблема моделізації. Кожного разу, коли ви стикаєтеся з подібними комбінаторними ситуаціями, це явна ознака того, що ваша абстракція моделі, яка описує ситуацію, занадто груба. Ви, швидше за все, комбінуєте елементи, які повинні належати до різних моделей в одне ціле.

Якщо ви продовжуєте ламати свою модель, ви врешті-решт повністю розчинять цей комбінаторний ефект. Однак, пройшовши цей шлях, легко розгубитися у дизайні, створивши ще більший безлад, перфекціонізм тут не обов'язково є вашим другом.

Машини з кінцевим станом і двигуни з правилом - лише приклад того, як цю проблему можна зруйнувати та зробити більш керованою. Основна ідея тут полягає в тому, що хороший спосіб позбавитись від комбінаторної проблеми, такої, як це часто, - це створити дизайн і повторити його adusevuseam у вкладених рівнях абстракції, поки ваша система не працює на задовільному рівні. Зазначте, як фрактали використовуються для створення складних візерунків. Правила залишаються незмінними, незалежно від того, якщо ви дивитесь на вашу систему за допомогою мікроскопа або з високого огляду птахів.

Приклад застосування цього до вашого домену.

Ви намагаєтеся моделювати, як корови рухаються по місцевості. Хоча у вашому запитанні бракує деталей, я б здогадався, що ваша велика кількість ifs включає фрагмент рішення, наприклад, if cow.isStanding then cow.canRun = trueале ви забиваєтесь, додаючи, наприклад, деталі про місцевість. Тому для кожної дії, яку ви хочете здійснити, ви повинні перевірити всі аспекти, які ви можете придумати, і повторити ці перевірки для наступної можливої ​​дії.

Спочатку нам потрібна наша повторювана конструкція, яка в цьому випадку буде FSM для моделювання мінливих станів моделювання. Отже, перше, що я зробив би - це реалізувати довідковий FSM, визначаючи інтерфейс стану, інтерфейс переходу та, можливо, контекст переходуяка може містити спільну інформацію, яка повинна бути доступною для інших двох. Основна реалізація FSM переключиться з одного переходу на інший незалежно від контексту, саме тут надходить двигун правил. Двигун правил чітко включає в себе умови, які повинні бути виконані, якщо відбудеться перехід. Тут двигун правил може бути таким же простим, як і список правил, кожен з яких має функцію оцінки, що повертає булеву форму. Щоб перевірити, чи повинен відбутися перехід, перейдіть до списку правил, і якщо будь-яке з них оцінюється як помилкове, перехід не відбувається. Сам перехід буде містити код поведінки для зміни поточного стану FSM (та інших можливих завдань).

Тепер, якщо я починаю реалізовувати моделювання як єдиний великий FSM на рівні GOD, я закінчую багато можливих станів, переходів і т. Д. Якщо все-таки безлад виглядає так, як він виправлений, але насправді просто поширюється навколо: кожен ІФ тепер правило, яке виконує тест на конкретну інформацію контексту (яка на даний момент містить у собі все), і кожен орган IF знаходиться десь у перехідному коді.

Введіть фрактал розбиття: першим кроком буде створення FSM для кожної корови, де штати є власними внутрішніми станами корови (стояння, біг, ходьба, випас тощо), а переходи між ними впливатимуть на навколишнє середовище. Можливо, що графіка не є повною, наприклад, пасовище доступне лише з стоячого стану, будь-який інший перехід заборонено, оскільки просто відсутній у моделі. Тут ви ефективно розділяєте дані у двох різних моделях, корова та місцевість. У кожного свій набір властивостей. Ця розбивка дозволить вам спростити загальну конструкцію двигуна. Тепер замість того, щоб мати механізм єдиного правила, який вирішує всі, у вас є кілька, більш простих двигунів правил (по одному для кожного переходу), які вирішують дуже конкретні деталі.

Оскільки я повторно використовую той самий код для FSM, це в основному конфігурація FSM. Пам'ятаєте, коли ми згадували про DSL раніше? Тут DSL може принести багато корисного, якщо у вас є багато правил і переходів для написання.

Заглиблюючись

Тепер БОГу більше не доводиться стикатися з усією складністю управління внутрішніми станами корови, але ми можемо просунути її далі. Наприклад, існує велика кількість складностей в управлінні місцевістю. Тут ви вирішите, де достатньо розбиття. Якщо, наприклад, в БОГІ ви закінчите керувати динамікою місцевості (довга трава, грязь, суха грязь, коротка трава тощо), ми можемо повторити ту саму схему. Ніщо не заважає вам вбудовувати таку логіку в саму місцевість, витягуючи всі стани місцевості (довга трава, коротка трава, каламутна, суха тощо) у новий місцевий FSM з переходами між державами та, можливо, простими правилами. Наприклад, щоб потрапити в каламутний стан, двигун правил повинен перевірити контекст, щоб знайти рідини, інакше це неможливо. Тепер БОГ все ж спростився.

Ви можете доповнити систему FSM, зробивши їх автономними та додавши їм кожну нитку. Цей останній крок не є необхідним, але це дозволяє змінювати взаємодію системи динамічно, регулюючи як делегувати прийняття рішень (запуск спеціалізованого FSM або просто повертають попередньо певний стан).

Пам'ятаєте, як ми згадували, що переходи також можуть виконувати "інші можливі завдання"? Давайте дослідимо це, додавши можливість для різних моделей (FSM) спілкуватися один з одним. Ви можете визначити набір подій і дозволити кожному FSM зареєструвати слухача цих подій. Таким чином, якщо, наприклад, корова потрапляє в місцевість місцевості, шестигранна може зареєструвати слухачів для змін переходу. Тут це стає трохи хитро, тому що кожен FSM реалізований на дуже високому рівні без будь-якого знання конкретної галузі, в якій він знаходиться. Однак ви можете досягти цього, якщо корова опублікує список подій, і клітина може зареєструватися, якщо бачить події, на які вона може реагувати. Тут хороша ієрархія родини подій - це хороша інвестиція.

Ви все ще можете просунутись глибше, моделюючи рівень поживних речовин та цикл росту трави, за допомогою ... ви здогадалися ... трава 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);
   }
}

Або, якщо ви можете розробити лінійну програму, яка моделює поведінку корів із заданим числом входів, кожне обмеження може стати лінією в системі рівнянь. Потім ви можете перетворити це на модель Маркова, яку ви можете переробити.

Важко сказати, який правильний підхід підходить до вашої ситуації, але я думаю, у вас буде набагато простіший час, якщо ви вважаєте, що ваші обмеження є вкладом до вашої програми, а не кодом.

Ніхто не згадав про це, тому я подумав, що я це скажу прямо:

Тисячі правил "Якщо .. Тоді .. Інше" є ознакою погано розробленого додатку.

Хоча представлення даних щодо домену може виглядати як ці правила, ви абсолютно впевнені, що ваша реалізація повинна нагадувати представлення конкретного домену?

Будь ласка, використовуйте програмне забезпечення / мови комп’ютера, відповідні для виконання цього завдання. Matlab дуже часто використовується для моделювання складних систем, де ви можете мати буквально тисячі умов. Не за допомогою клавіш if / then / else, а шляхом чисельного аналізу. R - це комп'ютерна мова з відкритим кодом, яка заповнена інструментами та пакетами для того ж. Але це означає, що ви також повинні перезапустити свою модель в більш математичному плані, так що ви можете включати як основні впливи, так і взаємодії між впливами в моделях.

Якщо ви ще цього не зробили, будь ласка, пройдіть курс з моделювання та моделювання. Останнє, що вам слід зробити, - це розглянути можливість написання такої моделі з точки зору if - тоді - else. У нас є ланцюги Монте Карло Маркова, підтримуючі векторні машини, нейронні мережі, прихований змінний аналіз, ... Будь ласка, не кидайте себе на 100 років назад, ігноруючи багатство на наявних у вас інструментах для моделювання.

Двигуни правил можуть допомогти, тому що якщо їх так багато, якщо / тоді правил, можливо, буде корисно перенести їх в одне місце поза програмою, де користувачі можуть редагувати їх, не знаючи мови програмування. Також можуть бути доступні засоби візуалізації.

Ви також можете подивитися на рішення логічного програмування (наприклад, Prolog). Ви можете швидко змінити список висловлювань if / then і зробити так, як виглядати, чи будь-яка комбінація входів призведе до певних результатів і т. Д. Це також може бути більш чистим в логіці предикатів першого порядку, ніж як процедурний код (або як як об'єктно-орієнтований код).

На мене раптом осяяло:

Потрібно використовувати дерево навчання з рішення (алгоритм ID3).

Ймовірно, що хтось реалізував це на вашій мові. Якщо ні, ви можете перенести існуючу бібліотеку

Це більше відповідь на вікі спільноти, агрегування різноманітних інструментів моделювання, запропонованих іншими відповідями, я тільки що додав додаткові посилання на ресурси.

Я не думаю, що не потрібно повторювати, що ви повинні використовувати інший підхід до тисяч твердо кодованих тверджень if / else.

• Програмування DSL (мова для домену)
• Марківська модель / Марківський процес прийняття рішення
• Алгоритм Rete net / Rete
• Експертна система
• Матлаб , (Вікіпедія)
• R

Кожна велика програма містить тисячі if-then-elseзаяв, не враховуючи інших елементів управління потоком, і ці програми все ще налагоджуються та підтримуються, незважаючи на їх складність.

Також кількість заяв не робить потік непередбачуваним . Асинхронне програмування робить. Якщо ви використовуєте детерміновані алгоритми синхронно, ви матимете 100% передбачувану поведінку щоразу.

Вам, мабуть, слід краще пояснити, що ви намагаєтеся зробити на переливанні стека чи перегляді коду, щоб люди могли запропонувати точні методи рефакторингу . Ви також можете задати більш точні запитання, як-от "Як я уникаю вкладати занадто багато ifвисловлювань <з урахуванням фрагмента коду>".

Зробіть вашу програму керованою, добре розробивши її. Створіть свою програму, розділивши різні бізнес-логіки на окремі класи / модулі. Пишіть одиничні тести, які перевіряють кожен із цих класів / модулів окремо. Це дуже важливо і допоможе вам забезпечити реалізацію ділової логіки так, як очікувалося.

Напевно, не знайдеться єдиного способу створити вихід із своєї проблеми, але ви можете керувати її складністю по частинах, якщо спробуєте розділити різні області, де ви опинитесь як писати великі блоки, якщо заяви і застосовувати рішення до кожної з цих менших проблем.

Погляньте на такі методи, як правила, про які говорилося в Refactoring, про шляхи розбиття великих умовних умов на керовані фрагменти - наприклад, кілька класів із загальним інтерфейсом можуть замінити випадок справи.

Вихід рано, також велика допомога. Якщо у вас є помилки, вимкніть їх у дорогу на початку функції, кинувши виняток або повернувшись, а не гніздо.

Якщо ви розбиєте свої умови на функції предикатів, можливо, простіше їх слідкувати. Крім того, якщо ви можете отримати їх у стандартній формі, можливо, їх можна отримати в структурі даних, яка будується динамічно, а не в жорсткому коді.

Я б запропонував вам скористатися двигуном правил. У випадку з Java, jBPM або Oracle BPM можуть бути корисними. Двигуни правил в основному дозволяють налаштувати додаток через XML.

Проблема не в тому, що добре вирішується "правилами", чи описується процедурним кодексом "якщо-то", чи численними рішеннями правил, розробленими для бізнес-програм. Машинне навчання забезпечує низку механізмів моделювання таких сценаріїв.

Принципово потрібно сформулювати певну схему для конкретного представлення факторів (наприклад, сонця, вітру, джерела їжі, раптових подій тощо), що впливають на "систему" (тобто корів на пасовищі). Незважаючи на хибну думку, що можна створити реальне ціннісне функціональне представлення, на відміну від дискретного, жоден комп’ютер у реальному світі (включаючи нервову систему людини) не базується на реальній цінності або обчислюється на основі реальних значень.

Отримавши числове представлення відповідних факторів, ви можете побудувати будь-яку з декількох математичних моделей. Я б запропонував двосторонній графік, де один набір вузлів представляє корів, а другий деяку одиницю пасовища. Корова в будь-якому випадку займає деяку одиницю пасовища. Тоді для кожної корови існує корисна цінність, пов'язана з поточними та іншими одиницями пасовища. Якщо модель передбачає, що корова прагне оптимізувати (будь-який такий спосіб для корови) корисності своєї одиниці пасовища, то корови будуть рухатися від одиниці до одиниці, намагаючись оптимізувати.

Стільниковий автомат добре працює для виконання моделі. Математика, що лежить в основі справжнього математичного світу, що мотивує рух корів, - це модель градієнта поля. Корови переходять від позицій сприйнятої нижчої цінності корисності до позицій сприйнятої більшої корисності.

Якщо хтось вводить зміни в навколишнє середовище в систему, то він не перейде до стійкого рішення положення розміщення корів. Це також стане моделлю, до якої можна застосувати аспекти теорії ігор; не те, що таке обов'язково багато би додало до цієї справи.

Перевага тут - забій корів або придбання нових корів можна легко керувати, віднімаючи і додаючи клітини "корів" до двобічного графіка, поки модель працює.

Я не думаю, що ви повинні визначати так багато тверджень, якщо інакше. З моєї точки зору, у вашої проблеми є кілька компонентів:

• Він повинен бути асинхронним або багатопоточним, тому що у вас є кілька корів з різними особистостями, різної конфігурації. Кожна корова запитує себе, в якому напрямку рухатися перед наступним кроком. На мою думку, код синхронізації є поганим інструментом для вирішення цієї проблеми.

• Конфігурація дерева рішень постійно змінюється. Це залежить від положення фактичної корови, погоди, часу, рельєфу місцевості тощо. Замість того, щоб будувати складне дерево «інше», я думаю, що ми повинні зменшити проблему до троянди вітру чи напрямку - функції ваги : рисунок 1 - напрям - вагові функції для деяких правил

  Корова завжди повинна йти в той бік, який має найбільшу вагу. Тож замість того, щоб будувати велике дерево рішень, ви можете додати набір правил (з різним напрямком - ваговими функціями) для кожної корови та просто обробляти результат кожен раз, коли ви запитуєте напрямок. Ви можете переналаштувати ці правила шляхом кожної зміни позиції або з часом, або ви можете додати ці деталі як параметри, кожне правило має отримати. Це рішення про реалізацію. Найпростіший спосіб отримати напрямок - додати просту петлю від 0 ° до 360 ° з кроком 1 °. Після цього ви можете порахувати загальну вагу кожного 360 напрямку та пропустити функцію max (), щоб отримати правильний напрямок.

• Для цього вам не обов'язково потрібна нейронна мережа, лише один клас для кожного правила, один клас для корів, можливо, для місцевості тощо тощо та один клас для сценарію (наприклад, 3 корови з різними правилами & 1 конкретна місцевість). фіг.2 - вузли асинхронного рішення програми асинхронізації корів

  • червоний для напряму обміну повідомленнями - карта ваги через правила
  • синій для оновлення орієнтації та положення після прийняття рішення
  • зелений для оновлення введення після оновлення орієнтації та положення
  • чорний для отримання входів

  Примітка: можливо, вам знадобиться рамка обміну повідомленнями, щоб реалізувати щось подібне

  Отже, якщо навчання корів не є частиною вашої проблеми, вам не потрібна нейронна мережа або генетичні алгоритми. Я не фахівець з ШІ, але, мабуть, якщо ви хочете пристосувати своїх корів до реальних, то ви можете це зробити просто за допомогою генетичного алгоритму та відповідного набору правил. Якщо я добре розумію, тобі потрібна популяція корів із налаштуваннями випадкових правил. Після цього ви можете порівняти поведінку реальних корів з поведінкою вашої модельної популяції та зберегти 10%, які йдуть найближчим шляхом до реальних. Після цього ви можете додати нові обмеження конфігурації правил до вашої фабрики корів на основі 10%, яку ви зберегли, та додати нових випадкових корів до популяції тощо, поки ви не отримаєте модельну корову, яка веде себе так само, як справжні ...

Я додам, що це може бути так, що якщо у вас справді є тисячі АБО ... ТОГО правил, ви можете переоцінити. Оскільки це варто, переговори з моделювання нейронної мережі часто починають з того, що за допомогою "простого набору правил" вони можуть генерувати досить складну та досить реальну поведінку, що відповідає дійсності (у таких випадках справжні нейрони в дії). Отже, ви впевненівам потрібні тисячі умов? Я маю на увазі, окрім 4-5 аспектів погоди, розташування джерел їжі, раптових подій, скотарства та місцевості, чи справді у вас буде ще багато змінних? Звичайно, якби ви намагалися зробити всі можливі перестановки комбінування цих умов, то ви могли б легко мати багато тисяч правил, але це не правильний підхід. Можливо, нечіткий підхід до логічного стилю, коли різні чинники вводять упередження щодо місця розташування кожної корови, що поєднуються із загальним рішенням, дозволить вам зробити це за набагато меншими правилами.

Я також погоджуюся з усіма іншими, що набір правил повинен бути окремим від загального потоку коду, щоб ви могли легко налаштувати його, не змінюючи програму. Ви навіть можете придумати конкуруючі набори правил і подивитися, як вони поступають з реальними даними про рух корів. Звучить весело.

Згадано експертні системи, які є областю ШІ. Щоб трохи розширити їх, читання на Inference Engine може допомогти вам у цьому. Пошук у Google може бути більш корисним - написання DSL - це легка частина, ви можете це зробити тривіально за допомогою аналізатора, як Gold Parser. Важка частина полягає в тому, щоб скласти своє дерево рішень і ефективно їх виконувати.

Багато медичних систем вже використовують ці двигуни, наприклад, веб-сайт NHS Direct Великобританії .

Якщо ви .NET'er, то Infer.NET може бути корисним для вас.

Оскільки ви дивитесь на рух корів, вони застрягають у напрямку 360 градусів (корови не можуть літати.) Ви також маєте швидкість, яку ви подорожуєте. Це можна визначити як вектор.

А тепер як ти маєш справу з такими речами, як положення сонця, схил пагорба, гучний шум?

Кожен із ступенів був би змінною, що означала б бажання йти в цьому напрямку. Скажіть, гілочка вправо від корови на 90 градусів (якщо корова стикається з 0 градусами). Бажання йти праворуч знизиться, а бажання піти 270 (зліва) підніметься. Пройдіть усі подразники, додаючи або віднімаючи їх вплив на бажання корів рухатись у напрямку. Як тільки всі подразники будуть застосовані, корова піде у напрямку найвищого бажання.

Ви також можете застосовувати градієнти, щоб стимули не повинні бути двійковими. Наприклад, пагорб не прямо в одну сторону. Можливо, корова знаходиться в долині, або на дорозі на пагорбі були її плоскі прямо вперед, на 45 * невеликий вгору пагорб при 90 * невеликий вниз пагорб. На 180 * крутий пагорб.

Потім можна відрегулювати вагу події, і це напрямок впливу. Замість списку, якщо немає, у вас є один тест, який шукає макс. Крім того, коли ви хочете додати подразники, ви можете просто застосувати його перед тестом, і вам не доведеться мати справу з додаванням все більшої складності.

Замість того, щоб сказати, що корова піде в будь-якому напрямку 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.  */
}