Как можно управлять тысячами правил IFâ € | THENâ € | ELSE?

Я рассматриваю возможность создания приложения, которое в его основе будет состоять из тысяч операторов if ... then ... else. Цель приложения - предсказать, как коровы перемещаются в любом ландшафте. На них воздействуют такие вещи, как солнце, ветер, источник пищи, внезапные события и т. Д.

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

Я немного читал о механизмах правил, но я не вижу, как они справятся с этой сложностью.

208 голосов | спросил 6 revs, 2 users 100%
David
1 Jam1000000amThu, 01 Jan 1970 03:00:00 +030070 1970, 03:00:00

18 ответов


71

Язык логического программирования Prolog может быть тем, что вы ищете. Ваше заявление о проблеме недостаточно для меня, чтобы оценить, хорошо ли это подходит, но это похоже на то, что вы говорите.

Программа Prolog состоит из фактов и правил, которые применяются. Вот простое примерное правило, в котором говорится: «Корова перемещается в место, если корова голодна, и в новом месте больше пищи, чем в старом месте»:

move_to (Корова, местоположение): -
  голодный (корова),
  current_location (Cow, OldLoc),
  food_in (OldLoc, OldFood), food_in (Location, NewFood),
  NewFood> OldFood.

Все вещи заглавными буквами являются переменными, то, что вы не знаете значения. Пролог пытается найти значения для этих переменных, которые удовлетворяют всем условиям. Этот процесс выполняется с помощью мощного алгоритма, называемого унификацией, который является сердцем Prolog и аналогичных программных сред.

В дополнение к правилам предоставляется база данных фактов. Простым примером, который работает с приведенными выше правилами, может быть что-то вроде:

current_location (white_cow, пастбище).

current_location (black_cow, barn).
голодный (black_cow).

current_location (angry_bull, лес).
голодный (angry_bull).

food_in (сарай, 3).
food_in (пастбище, 5).
food_in (лес, 1).

Обратите внимание, что white_cow и пастбище и т. д. не написаны в столицах. Они не являются переменными, они являются атомами.

Наконец, вы делаете запрос и спрашиваете, что произойдет.

? - move_to (white_cow, Destination).
Нет.
? - move_to (black_cow, Destination).
Место назначения = пастбище
? - move_to (Cow, Destination).
Cow = black_cow, Destination = пастбище
Cow = angry_bull, Destination = barn
Cow = angry_bull, Destination = пастбище

В первом запросе спрашивается, куда будет двигаться белая корова. Учитывая правила и факты выше, ответ №. Это можно интерпретировать как «я не знаю» или «оно не движется» в зависимости от того, что вы хотите.

Второй запрос спрашивает, куда движется черная корова. Он перемещается на пастбище, чтобы поесть.

В последнем запросе спрашивается, куда двигаются все коровы. В результате вы получаете все возможное (Cow, Destination), которое имеет смысл. В этом случае черный бык движется на пастбище, как ожидалось. Однако у злого быка есть два варианта, которые соответствуют правилам, он может либо перейти на пастбище, либо в сарай.

Примечание. Прошло много лет с тех пор, как я в последний раз написал Prolog, все примеры могут быть не синтаксически действительными, но идея должна быть правильной.

ответил Odalrick 15 PMpWed, 15 Apr 2015 14:13:21 +030013Wednesday 2015, 14:13:21
137

Решение проблемы if web позволяет создать механизм правил, в котором каждое конкретное правило кодируется независимо. Дальнейшим уточнением для этого было бы создание языка, специфичного для домена (DSL), для создания правил, однако только DSL смещает проблему только с одной базовой базы (основной) на другую (DSL). Без структуры DSL не будет лучше, чем родной (Java, C # и т. Д.), Поэтому мы вернемся к нему после того, как найдем улучшенный структурный подход.

Основная проблема заключается в том, что у вас проблема моделирования. Всякий раз, когда вы сталкиваетесь с такими комбинаторными ситуациями, это явный признак того, что ваша модельная абстракция, описывающая ситуацию, слишком груба. Вы, скорее всего, объединяете элементы, которые должны принадлежать различным моделям в одном объекте.

Если вы продолжаете разрушать свою модель, вы в конечном итоге полностью растворите этот комбинаторный эффект. Однако, принимая этот путь, вы легко теряетесь в своем дизайне, создавая еще больший беспорядок, перфекционизм здесь не обязательно ваш друг.

Конечные машины и механизмы правил - это всего лишь пример того, как эту проблему можно разбить и сделать более управляемой. Основная идея здесь заключается в том, что хороший способ избавиться от комбинаторной проблемы, такой как это, часто создавать дизайн и повторять его ad-tauseam во вложенных уровнях абстракции , пока ваша система не будет удовлетворительно работать. Сродни тому, как фракталы используются для создания сложных шаблонов. Правила остаются теми же, независимо от того, смотрите ли вы на свою систему с помощью микроскопа или с высоты птичьего полета.

Пример применения этого в вашем домене.

Вы пытаетесь моделировать, как коровы движутся по ландшафту. Хотя ваш вопрос не содержит подробностей, я бы предположил, что ваше большое количество ifs включает в себя фрагмент решения, например , если cow.isStanding then cow.canRun = true, но вы увязнете, когда вы добавляете детали местности, например. Поэтому для каждого действия, которое вы хотите предпринять, вам нужно проверить все аспекты, о которых вы можете подумать, и повторить эти проверки для следующего возможного действия.

Сначала нам нужна наша повторяемая конструкция, которая в этом случае будет FSM для моделирования изменяющихся состояний моделирования. Поэтому первое, что я хотел бы сделать, это реализовать ссылку FSM, определяющую интерфейс state , интерфейс transition и, возможно, переход контекст , который может содержит общую информацию, доступную для двух других. Основная реализация FSM будет переключаться с одного перехода на другой независимо от контекста, в этом случае появляется механизм правил. Механизм правил четко инкапсулирует условия, которые должны выполняться, если переход должен произойти. Механизм правил здесь может быть таким же простым, как список правил, каждый из которых имеет функцию оценки, возвращающую логическое значение. Чтобы проверить, должен ли произойти переход, мы перебираем список правил и, если какой-либо из них оценивается как false, переход не выполняется. Сам переход будет содержать код поведенческий , чтобы изменить текущее состояние FSM (и другие возможные задачи).

Теперь, если я начну реализовывать симуляцию как один большой FSM на уровне GOD, я получаю LOT возможных состояний, переходов и т. д. Повреждение if-else похоже, что оно исправлено, но на самом деле оно просто распространяется: каждый IF теперь является правилом, которое выполняет тест против конкретной информации контекста (который в этот момент в значительной степени содержит все), и каждый модуль IF находится где-то в коде перехода.

Введите разбивку фракталов: первым шагом будет создание FSM для каждой коровы, где состояния являются собственными внутренними состояниями коровы (стоя, бегом, ходьбой, выпасом и т. д.), и переходы между ними будут затронуты средой. Возможно, что график не является полным, например, выпаса доступно только из состояния стояния, любой другой переход исчезает, потому что просто отсутствует в модели. Здесь вы эффективно разделяете данные в двух разных моделях: корове и местности. Каждый из них имеет свои собственные свойства. Эта разбивка позволит вам упростить общий дизайн двигателя. Теперь вместо того, чтобы иметь единственный механизм правил, который решает все, у вас есть несколько, более простых механизмов правил (по одному для каждого перехода), которые определяют очень конкретные детали. Многие игровые компании используют конечные конечные машины, такие как это, чтобы решить такие аспекты.

Поскольку я повторно использую тот же код для FSM, это в основном конфигурация FSM. Помните, когда мы упомянули о DSL раньше? Это то, где DSL может принести много пользы, если у вас много правил и amp; переходы для записи.

Переход глубже

Теперь GOD больше не имеет дело со всей сложностью управления внутренними состояниями коровы, но мы можем продвигать его дальше. Например, в управлении рельефом все еще много сложностей. Вот где вы решаете, где этого достаточно. Если, например, вваш БОГ, вы в конечном итоге управляете динамикой ландшафта (длинная трава, грязь, сухая грязь, короткая трава и т. д.), мы можем повторить ту же картину. Ничто не мешает вам встраивать такую ​​логику в саму местность, извлекая все состояния ландшафта (длинную траву, короткую траву, мутную, сухую и т. Д.) В новый FSM ландшафта с переходами между состояниями и, возможно, простыми правилами. Например, чтобы попасть в грязное состояние, механизм правил должен проверить контекст, чтобы найти жидкости, иначе это невозможно. Теперь БОГ стал еще проще.

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

Помните, как мы упоминали, что переходы также могут выполнять «другие возможные задачи»? Давайте рассмотрим это, добавив возможность для разных моделей (FSM) общаться друг с другом. Вы можете определить набор событий и разрешить каждому FSM регистрировать прослушиватель этих событий. Таким образом, если, например, корова войдет в гексагон местности, шестнадцатеричный регистр может регистрировать слушателей для изменений перехода. Здесь это немного сложно, потому что каждый FSM реализован на очень высоком уровне без каких-либо знаний о конкретном домене, который он обслуживает. Однако вы можете добиться этого, если корова опубликует список событий, и ячейка может зарегистрироваться, если она увидит события, на которые она может реагировать. Хорошая иерархия семьи событий здесь хорошая инвестиция. Таким образом, если корова начинает пастись, участок местности может записывать время выпаса и через некоторое время может перейти от длинной травы к короткой траве, тем самым сигнализируя о корове, здесь ничего не остается.

Вы можете еще глубже продвигаться, моделируя уровни питательных веществ и цикл роста травы, с ... вы догадались ... трава FSM, встроенная в собственную модель паттерна ландшафта.

Если вы выдвигаете идею достаточно далеко, у Бога очень мало дел, так как все аспекты в значительной степени самоуправляемы, освобождая время, чтобы тратить на более благочестивые вещи.

Резюме

Как указано выше, FSM здесь не является решением, а просто средством для иллюстрации того, что решение такой проблемы не найдено в коде для одного, а как вы моделируете свою проблему. Есть, скорее всего, другие решения, которые возможны и, скорее всего, намного лучше, чем мое предложение FSM. Однако подход «фракталов» остается хорошим способом справиться с этой трудностью. Если все сделано правильно, вы можете динамически распределять более глубокие уровни, когда это имеет значение, давая более простые модели, где это имеет меньшее значение. Вы можете изменять очереди и применять их, когда ресурсы становятся более доступными. В последовательности действий, возможно, не все так важно, чтобы вычислить перенос питательных веществ с коровы на патч травы. Тем не менее, вы можете записывать эти переходы и применять изменения в более позднее время или просто приближаться с образованной догадкой, просто заменив механизмы правил или, возможно, заменив реализацию FSM в целом более простой наивной версией для элементов, которые не находятся в прямом поле интерес (чтобы корова на другом конце поля) позволяла более детально взаимодействовать, чтобы получить фокус и большую долю ресурсов. Все это, не пересматривая систему в целом; поскольку каждая часть хорошо изолирована, становится легче создавать замену замены, ограничивая или расширяя глубину вашей модели. Используя стандартный дизайн, вы можете опираться на это и максимизировать инвестиции, сделанные в специальных инструментах, таких как DSL, для определения правил или стандартного словаря для событий, начиная с очень высокого уровня и при необходимости добавляя уточнения.

Я бы представил пример кода, но это все, что я могу себе позволить прямо сейчас.

ответил Odalrick 15 PMpWed, 15 Apr 2015 14:13:21 +030013Wednesday 2015, 14:13:21
89

Похоже, что все эти условные утверждения, о которых вы говорите, действительно должны быть данными, которые настраивают вашу программу, а не часть вашей программы. Если вы можете обращаться с ними таким образом, вы сможете изменить способ работы своей программы, просто изменив конфигурацию, вместо того, чтобы изменять свой код и перекомпилировать каждый раз, когда хотите улучшить свою модель.

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

 if (sunLevel> 0,75) {
   foreach (корова в коровах) {
       cow.desireForShade + = 0.5;
   }
}
если (осаждение> 0,2) {
   foreach (корова в коровах) {
       cow.desireForShelter + = 0.8;
   }
}

вместо этого вы можете иметь код, который выглядит так:

 foreach (правило в правилах) {
   foreach (корова в коровах) {
      cow.apply (правило);
   }
}

Или, если вы можете разработать линейную программу, которая моделирует поведение коровы с учетом количества входов, каждое ограничение может стать линией в системе уравнений. Затем вы можете превратить это в марковскую модель, которую вы можете повторить.

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

ответил Odalrick 15 PMpWed, 15 Apr 2015 14:13:21 +030013Wednesday 2015, 14:13:21
44

Никто не упомянул об этом, поэтому я подумал, что я бы сказал это явно:

Тысячи правил «If .. Then .. Else» являются признаком плохо разработанного приложения.

Пока представление данных о конкретных доменах может выглядеть как эти правила, вы абсолютно уверены, что ваша реализация должна напоминать представление, специфичное для домена?

ответил Odalrick 15 PMpWed, 15 Apr 2015 14:13:21 +030013Wednesday 2015, 14:13:21
17

Пожалуйста, используйте программные /компьютерные языки, подходящие для задачи. Matlab используется очень часто для моделирования сложных систем, где у вас действительно есть буквально тысячи условий. Не использовать выражения if /then /else, а путем численного анализа. R - это компьютер с открытым исходным кодом, который заполнен инструментами и пакетами, чтобы сделать то же самое. Но это означает, что вам также нужно пересчитать свою модель в более математических терминах, поэтому вы можете включить как основные влияния, так и взаимодействия между влияниями в моделях.

Если вы еще этого не сделали, следуйте инструкциям по моделированию и симуляции. Последнее, что вам нужно сделать, - это написать такую ​​модель, как if-then-else. У нас есть сети monte carlo markov, поддерживающие векторные машины, нейронные сети, анализ скрытых переменных ... Пожалуйста, не бросайте 100 лет назад, игнорируя богатство доступных инструментов моделирования.

ответил Odalrick 15 PMpWed, 15 Apr 2015 14:13:21 +030013Wednesday 2015, 14:13:21
13

Механизмы правил могут помочь, потому что, если существует так много правил if /then, может быть полезно получить их все в одном месте за пределами программы, где пользователи могут редактировать их, не зная языка программирования. Кроме того, инструменты визуализации могут быть доступны.

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

ответил Odalrick 15 PMpWed, 15 Apr 2015 14:13:21 +030013Wednesday 2015, 14:13:21
11

Меня вдруг озарило:

Вам необходимо использовать Дерево обучения принятия решений (алгоритм ID3).

Скорее всего, кто-то реализовал его на вашем языке. Если нет, вы можете перенести существующую библиотеку

ответил Odalrick 15 PMpWed, 15 Apr 2015 14:13:21 +030013Wednesday 2015, 14:13:21
10

Это скорее ответ сообщества wiki, агрегирующий различные инструменты моделирования, предлагаемые другими ответами, я только добавил дополнительные ссылки на ресурсы.

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

ответил Odalrick 15 PMpWed, 15 Apr 2015 14:13:21 +030013Wednesday 2015, 14:13:21
9

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

Кроме того, количество операторов не делает поток непредсказуемым . Асинхронное программирование. Если вы используете синхронно детерминированные алгоритмы, каждый раз вы будете иметь 100% прогнозируемое поведение.

Вероятно, вам следует объяснить лучше , что вы пытаетесь сделать в переполнении стека или Обзор кода чтобы люди могли предложить вам точные методы рефакторинга . Вы также можете задать более точные вопросы, такие как «Как избежать чрезмерного вложенности выражений if <с учетом фрагмента кода>".

ответил Odalrick 15 PMpWed, 15 Apr 2015 14:13:21 +030013Wednesday 2015, 14:13:21
2

Сделайте ваше приложение управляемым, разработав его хорошо. Разработайте приложение, разделив различные бизнес-логики на отдельные классы /модули. Напишите модульные тесты, которые проверяют каждый из этих классов /модулей по отдельности. Это имеет решающее значение и поможет вам обеспечить выполнение бизнес-логики, как ожидалось.

ответил Odalrick 15 PMpWed, 15 Apr 2015 14:13:21 +030013Wednesday 2015, 14:13:21
2

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

Посмотрите на методы, подобные правилам, о которых говорится в Рефакторинг для способов разбить большие условные обозначения на управляемые куски - например, несколько классов с общим интерфейсом могут заменить оператор case.

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

Если вы нарушаете условия в предикатных функциях, их легче отслеживать. Кроме того, если вы можете получить их в стандартную форму, возможно, их можно будет получить в структуре данных, которая будет построена динамически, а не жестко закодированной.

ответил Odalrick 15 PMpWed, 15 Apr 2015 14:13:21 +030013Wednesday 2015, 14:13:21
2

Я предлагаю вам использовать механизм правил. В случае Java, jBPM или Oracle BPM могут быть полезны. Механизмы правил в основном позволяют настраивать приложение через XML.

ответил Odalrick 15 PMpWed, 15 Apr 2015 14:13:21 +030013Wednesday 2015, 14:13:21
2

Проблема не очень хорошо решена «правилами», независимо от того, описывается ли она «if-then» процедурным кодом или многочисленными правилами, разработанными для бизнес-приложений. Машиноведение предоставляет ряд механизмов для моделирования таких сценариев.

В сущности, нужно сформулировать некоторую схему для условного представления факторов (например, солнца, ветра, источника пищи, внезапных событий и т. д.), влияющих на «систему» ​​(т. е. коровы на пастбище). Несмотря на ошибочное убеждение в том, что можно создать реальное функциональное представление, а не дискретное, ни один компьютер в реальном мире (включая нервную систему человека) не будет основан на реальных значениях или вычисляется на основе реальных значений.

Как только у вас есть численное представление для соответствующих факторов, вы можете построить любую из нескольких математических моделей. Я бы предложил двудольный граф, где один набор узлов представляет коров, а другой - часть площади пастбищ. Корова в любом случае занимает часть площади пастбищ. Для каждой коровы существует значение полезности, связанное с текущим и всеми другими единицами пастбищ. Если модель предполагает, что корова стремится оптимизировать (что бы это ни значило для коровы) значение полезности своей единицы пастбищ, тогда коровы будут двигаться от единицы к единице в попытке оптимизировать.

Ячейный автомат хорошо работает для выполнения модели. Основополагающая математика в реальном значении математического мира, мотивирующего корову, является моделью градиента поля. Коровы перемещаются с позиций воспринимаемого более низкого значения полезности на позиции воспринимаемого более высокого значения полезности.

Если кто-то вводит изменение окружающей среды в систему, то он не будет двигаться в устойчивое решение для размещения коровы. Он также станет моделью, к которой могут быть применены аспекты теории игры; не то, что это обязательно добавит много к этому случаю.

Преимущество здесь в том, что убойные коровы или приобретение новых коров могут легко управляться путем вычитания и добавления клеток «коровы» к двудольному графику, в то время как модель работает.

ответил Odalrick 15 PMpWed, 15 Apr 2015 14:13:21 +030013Wednesday 2015, 14:13:21
1

Я не думаю, что вы должны определить так много операторов if-else. С моей точки зрения ваша проблема состоит из нескольких компонентов:

  • Он должен быть асинхронным или многопоточным, потому что у вас есть несколько коров с разными личностями, с другой конфигурацией. Каждая корова спрашивает себя, в каком направлении идти до следующего шага. По-моему, код синхронизации - плохой инструмент для этой проблемы.

  • Конфигурация дерева решений постоянно изменяется. Это зависит от положения фактической коровы, погоды, времени, местности и т. Д. Вместо того, чтобы строить сложное дерево if-else, я думаю, что мы должны уменьшить проблему до роза ветра или функция направления - вес: figure 1 Рисунок 1 - функции направления - веса для некоторых правил

    Корова всегда должна идти в направлении, которое имеет наибольший вес. Поэтому вместо построения большого дерева решений вы можете добавить набор правил (с различными функциями направления - веса) к каждой корове и просто обрабатывать результат каждый раз, когда вы задаете направление. Вы можете перенастроить эти правила путем изменения каждой позиции или путем передачи времени, или вы можете добавить эти данные в качестве параметров, каждое правило должно получить. Это решение для реализации. Самый простой способ получить направление, добавить простой цикл от 0 ° до 360 ° с шагом 1 °. После этого вы можете подсчитать суммарный вес каждого 360-го направления и выполнить функцию max (), чтобы получить правильное направление.

  • Для этого вам не обязательно нужна нейронная сеть, только один класс для каждого правила, один класс для коров, возможно, для местности и т. д. и один класс для сценария (например, 3 коровы с различные правила и 1 конкретный ландшафт). figure2 Рисунок 2 - узлы и соединения решений асинхронного приложения для коров

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

    Примечание: вам, вероятно, понадобится среда обмена сообщениями для реализации чего-то вроде этого

    Итак, если учить коров не является частью вашей проблемы, вам не нужна нейронная сеть или генетические алгоритмы. Я не эксперт в области ИИ, но я думаю, если вы хотите адаптировать своих коров к реальным, тогда вы можете сделать это просто с помощью генетического алгоритма и правильного набора правил. Если я хорошо понимаю, вам нужна популяция коров со случайными настройками правил. После этого вы можете сравнить поведение реальных коров с поведением вашей модели населения и сохранить 10%, которые идут ближе всего к реальным. После этого вы можете добавить новые ограничения конфигурации правил в свою фабрику коровы на основе 10%, которую вы сохранили, и добавить новых случайных коров в популяцию и так далее, пока не получите модельную корову, которая ведет себя так же, как настоящие ...

ответил Odalrick 15 PMpWed, 15 Apr 2015 14:13:21 +030013Wednesday 2015, 14:13:21
0

Я бы добавил, что может быть так, что если у вас действительно есть тысячи IF ... ТОГДА вы можете переопределить правила. Для того, что стоит, переговоры по моделированию нейронной сети, которые я посещал, часто начинаются с того, что с помощью «простого набора правил» они могут генерировать довольно сложное и разумное поведение, совместимое с реальностью (в тех случаях реальные нейроны в действии). Итак, вы sure нужны тысячи условий? Я имею в виду, кроме 4-5 аспектов погоды, расположения источников пищи, внезапных событий, пастбищ и местности, действительно ли у вас будет гораздо больше переменных? Конечно, если вы попытались сделать все возможные перестановки в сочетании этих условий, тогда вы можете легко иметь много тысяч правил, но это неправильный подход. Возможно, подход с нечетким логическим стилем, в котором различные факторы вводят предвзятость в отношении местоположения каждой коровы, которые в совокупности с общим решением позволят вам сделать это в гораздо меньшем количестве правил.

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

ответил Odalrick 15 PMpWed, 15 Apr 2015 14:13:21 +030013Wednesday 2015, 14:13:21
0

Были упомянуты экспертные системы, которые являются областью ИИ. Чтобы немного рассказать об этом, вы можете прочитать это на Inference Engines . Поиск Google может быть более полезным - писать DSL - это легкая часть, вы можете сделать это тривиально с парсером, таким как Gold Parser. Трудная часть - это сборка вашего дерева решений и эффективное управление ими.

Многие медицинские системы уже используют эти двигатели, например, сайт NHS Direct .

Если вы являетесь пользователем .NET, Infer.NET может быть вам полезен.

ответил Odalrick 15 PMpWed, 15 Apr 2015 14:13:21 +030013Wednesday 2015, 14:13:21
0

Поскольку вы смотрите на движение коровы, они застревают в направлении 360 градусов (коровы не могут летать.) У вас также есть скорость, которую вы путешествуете. Это можно определить как вектор.

Теперь, как вы имеете дело с вещами, такими как положение солнца, склон склона холма, громкий шум?

Каждая из степеней будет переменной, означающей желание идти в этом направлении. Скажите, что с правой стороны коровы держится веточка на 90 градусов (при условии, что корова стоит 0 градусов). Желание идти направо спустится, и желание идти 270 (слева) будет расти. Пройдите все стимулы, добавляя или вычитая их влияние на желание коров идти в направлении. Как только все стимулы будут применены, корова пойдет в направлении наивысшего желания.

Вы также можете применять градиенты, чтобы стимулы не были бинарными. Например, холм не прямо в одном направлении. Возможно, корова находится в долине или на дороге на холме, ее плоская прямая впереди, на 45 * небольшой холм в 90 * небольшой холм. На 180 * крутой холм.

Затем вы можете настроить вес события и его влияние. Скорее тогда список if thens, у вас есть один тест, который ищет max. Также, когда вы хотите добавить стимулы, вы можете просто применить его перед тестом, и вам не придется иметь дело с добавлением все большей и большей сложности.

Вместо того, чтобы сказать, что корова отправится в любом направлении 360, вы можете просто сломать ее на 36 направлений. Каждый из них составляет 10 градусов

Вместо того, чтобы сказать, что корова отправится в любом направлении 360, вы можете просто сломать ее на 36 направлений. Каждый из них составляет 10 градусов. В зависимости от того, насколько конкретно вы должны быть.

ответил Odalrick 15 PMpWed, 15 Apr 2015 14:13:21 +030013Wednesday 2015, 14:13:21
-2

Использовать ООП. Как создать набор классов, которые обрабатывают базовые условия и запускать случайные методы для имитации того, что вы делаете.

Получить программиста, чтобы помочь.

class COW_METHODS {

    Функция = массив («Action1», «Action2», ... «ActionX»);

    функция doAction () {
       выполнение (Функция [случайное (1,5000]);
    }

    выполнение функции (DynamicFunction) {
        Exec (DynamicFunction ());
    }

    Функция Action1 () {
        поверни направо();
        есть траву();
    }
    /* добавлять функции для методов COW ... и т. д. * /
    /* и добавить классы для условий, наследующих их по мере необходимости * /
    /* сохранить объект для определения условий = Singleton и т. д. * /
}
ответил Odalrick 15 PMpWed, 15 Apr 2015 14:13:21 +030013Wednesday 2015, 14:13:21

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132