Пролог для начинающих - это плохая идея? - PullRequest
11 голосов
/ 21 июля 2011

Приложение, над которым я работаю, является своего рода «конфигуратором». Он написан на C #, и я даже написал движок правил для этого. Идея состоит в том, что существует множество логических утверждений, и пользователь может делать выбор. В зависимости от того, что они выбрали, некоторые другие предметы становятся обязательными или полностью недоступными.

Утверждения логики высказываний обычно принимают следующие формы:

A => ~X 
ABC => ~(X+Y) 
A+B => Q 
A(~(B+C)) => ~Q A <=> B

Символы:

=>  -- Implication
<=> -- Material Equivalence
~   -- Not
+   -- Or
Two letters side-by-side -- And

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

Кроме того, все доступные параметры находятся в иерархии. Например:

Outside
   Color
      Red
      Blue
      Green
   Material
      Wood
      Metal

Если подразумевается элемент на втором уровне (функция, такая как Цвет), то должен быть выбран элемент на третьем уровне (опция, например, Красный). Точно так же, если мы знаем, что функция является ложной, то все опции под ней также ложны.

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

Я думаю, что это может сработать, чтобы настроить идею компонентов, функций и опций. Затем установите отношения между then (например, если функция имеет значение false, то все ее параметры имеют значение false). Во время выполнения добавьте конкретные правила продукта. Затем передайте все выбранные пользователем функции, получая в качестве выходных данных, какие элементы являются истинными, а какие - ложными.

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

Некоторые вопросы, которые могут помочь в определении того, что я пытаюсь выяснить:

  1. Это звучит выполнимо?
  2. Я лаю не на том дереве?
  3. Есть ли какие-либо недостатки или проблемы при попытке создать все эти правила во время выполнения?
  4. Есть ли лучшая система для такого рода вещей, которую я мог бы втиснуть в приложение C # (Silverlight, если быть точным)?
  5. Существуют ли другие конкурирующие системы, которые мне следует изучить?
  6. У вас есть какой-нибудь общий совет по поводу такого рода вещей?

Заранее спасибо за совет!

Ответы [ 2 ]

7 голосов
/ 21 июля 2011
  1. Конечно, но у Пролога есть кривая обучения.
  2. Вывод на основе правил - это игра Пролога, хотя вам, возможно, придется переписать многие правила в предложения Рога .A+B => Q выполнимо (становится q :- a. q :- b. или q :- (a;b).), но другие ваши примеры должны быть переписаны, включая A => ~X.
  3. Зависит от вашего компилятора Prolog, в частности, поддерживает ли он индексирование для динамических предикатов.
  4. Поиск по таким терминам, как «проверка вперед», «механизм вывода» и «бизнес-правила».Различные сообщества продолжают придумывать разные термины для этой проблемы.
  5. Правила обработки ограничений (CHR) - это язык логического программирования, реализованный в виде расширения Prolog, который намного ближе к выводу на основе правил /двигатели прямого цепочки / бизнес-правил.Если вы хотите его использовать, вам все равно придется изучать базовый Пролог.
  6. Имейте в виду, что Пролог - это язык программирования , а не серебряная пуля для логического вывода.Это сокращает некоторые углы логики первого порядка, чтобы обеспечить эффективное вычисление.Вот почему он обрабатывает только операторы Horn: они могут отображаться один в один с помощью процедур / подпрограмм.
4 голосов
/ 22 июля 2011

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

Возьмем, к примеру, две пары значений атрибутовЦвет в {красный, синий, зеленый} и материал в {дерево, металл}.Они могут указывать ручку двери, при которой возможны не все комбинации:

knob(red,wood)   --> ['100101'].
knob(red,metal)  --> ['100102'].
knob(blue,metal) --> ['100202'].

Затем вы можете определить дверь как:

door ... --> knob ..., panel ...

Интересно, что вы не увидите никакой логической формулы в такихспецификация продукта, только факты и правила, и множество параметров, переданных вокруг.Вы можете использовать параметры в компоненте получения знаний.Просто выполнив необоснованные цели, вы можете получить возможные значения для пар значений атрибутов.Предикат setof / 3 будет сортировать и удалять дубликаты для вас:

?- setof(Color,Material^Bill^knob(Color,Material,Bill,[]),Values).
Value = [blue, red] 
?- setof(Material,Color^Bill^knob(Color,Material,Bill,[]),Values).
Material = [metal, wood] 

Теперь вы знаете диапазон атрибутов и можете позволить конечному пользователю последовательно выбирать атрибут и значение.Предположим, он берет атрибут Color и его значение blue.Диапазон атрибута Материал затем сжимается соответственно:

?- setof(Material,Bill^knob(blue,Material,Bill,[]),Values).
Material = [metal] 

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

?- knob(blue,metal,Bill,[]).
Bill = ['100202']

С наилучшими пожеланиями

PS:О, похоже, что идея спецификации материалов, использованная в конфигураторе продукта, восходит к Clocksin & Mellish.По крайней мере, я нахожу соответствующий комментарий здесь: http://www.amzi.com/manuals/amzi/pro/ref_dcg.htm#DCGBillMaterials

...