Prolog 初学者 - 这是一个坏主意吗？

发布于 2024-11-25 22:06:34 字数 1202 浏览 2 评论 0原文

我正在开发的应用程序是一种“配置器”。它是用 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

我对 Prolog 很陌生，但它似乎能够为我处理所有“规则处理”，让我摆脱当前的规则引擎（它可以工作，但它不像我想要的那么快或易于维护）。

此外，所有可用选项都属于一个层次结构。例如：

Outside
   Color
      Red
      Blue
      Green
   Material
      Wood
      Metal

如果隐含了第二级的项目（特征，例如颜色），则必须选择第三级的项目（选项，例如红色）。类似地，如果我们知道某个功能是错误的，那么它下面的所有选项也都是错误的。

问题是每种产品都有自己的一套规则。建立一个包含这些运算符作为谓词的知识库，然后在运行时开始构建产品的所有规则，这是一种合理的方法吗？

我想象它的工作方式是建立组件、功能和选项的想法。然后建立 then 之间的关系（例如，如果该特征为 false，则其所有选项均为 false）。在运行时，添加产品的特定规则。然后将所有用户的选择传递给一个函数，检索哪些项目为真、哪些项目为假作为输出。

我不知道我所问的问题的所有含义，因为我刚刚进入 Prolog，但我试图避免走上一条糟糕的道路并在此过程中浪费大量时间。

一些可能有助于确定我想要找出的问题的问题：

这听起来可行吗？
我是不是找错了树？
尝试在运行时创建所有这些规则是否有任何缺点或担忧？
对于此类事情是否有更好的系统，我可以将其挤入 C# 应用程序（确切地说是 Silverlight）？
我还应该检查其他竞争系统吗？
您对此类事情有什么一般建议吗？

预先感谢您的建议！

原文

The application I'm working on is a "configurator" of sorts. It's written in C# and I even wrote a rules engine to go with it. The idea is that there are a bunch of propositional logic statements, and the user can make selections. Based on what they've selected, some other items become required or completely unavailable.

The propositional logic statements generally take the following forms:

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

The symbols:

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

I'm very new to Prolog, but it seems like it might be able to handle all of the "rules processing" for me, allowing me to get out of my current rules engine (it works, but it's not as fast or easy to maintain as I would like).

In addition, all of the available options fall in a hierarchy. For instance:

Outside
   Color
      Red
      Blue
      Green
   Material
      Wood
      Metal

If an item at the second level (feature, such as Color) is implied, then an item at the third level (option, such as Red) must be selected. Similarly if we know that a feature is false, then all of the options under it are also false.

The catch is that every product has it's own set of rules. Is it a reasonable approach to set up a knowledge base containing these operators as predicates, then at runtime start buliding all of the rules for the product?

The way I imagine it might work would be to set up the idea of components, features, and options. Then set up the relationships between then (for instance, if the feature is false, then all of its options are false). At runtime, add the product's specific rules. Then pass all of the user's selections to a function, retrieving as output which items are true and which items are false.

I don't know all the implications of what I'm asking about, as I'm just getting into Prolog, but I'm trying to avoid going down a bad path and wasting lots of time in the process.

Some questions that might help target what I'm trying to find out:

Does this sound do-able?
Am I barking up the wrong tree?
Are there any drawbacks or concerns to trying to create all of these rules at runtime?
Is there a better system for this kind of thing out there that I might be able to squeeze into a C# app (Silverlight, to be exact)?
Are there other competing systems that I should examine?
Do you have any general advice about this sort of thing?

Thanks in advance for your advice!

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

故事还在继续 2024-12-02 22:06:35

当然可以，但是 Prolog 有一个学习曲线。
基于规则的推理是 Prolog 的游戏，尽管您可能必须将许多规则重写为 Horn 子句。 <代码>A+B => Q 是可行的（它变成 q :- a.q :- b. 或 q :- (a;b).），但您的其他示例必须被重写，包括A =>; 〜X。
取决于您的 Prolog 编译器，特别是它是否支持动态谓词的索引。
搜索“前向检查”、“推理引擎”和“业务规则”等术语。不同的社区不断为这个问题发明不同的术语。
约束处理规则(CHR)是一种逻辑编程语言，作为Prolog扩展实现，即更接近基于规则的推理/前向链接/业务规则引擎。不过，如果您想使用它，您仍然需要学习基本的 Prolog。
请记住，Prolog 是一种编程语言，而不是逻辑推理的灵丹妙药。它削减了一阶逻辑的一些角落，以保持事物的高效可计算性。这就是为什么它只处理 Horn 子句：它们可以与过程/子例程一对一映射。

回复收藏 0 原文

递刀给你 2024-12-02 22:06:35

您还可以添加 DCG 来生成物料清单。这个想法是
粗略地说，终端可用于指示子产品，并且
非终结符来定义越来越复杂的子产品组合
直到您获得最终的可配置产品。

以 {red, blue, green} 中的两个属性值对 Color 为例
以及{木材、金属}材质。这些可以指定一个门把手，由此
并非所有组合都是可能的：

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 及其值蓝色。
然后，Material 属性的范围相应缩小：

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

最后，当所有属性都指定完毕后，您就可以阅读文章了
子产品的数量。您可以通过添加一些来使用它来计算价格
为您提供有关商品编号的附加信息或生成的事实
订购清单等..：

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

最好的问候

P.S.：
哦，看来产品配置器中使用了物料清单的想法
回到 Clocksin &梅利什。至少我找到了对应的
在这里评论：
http://www.amzi.com/manuals/amzi/pro/ref_dcg .htm#DCGBillMaterials

You can also throw in DCGs to generate bill of materials. The idea is
roughly that terminals can be used to indicate subproducts, and
non-terminals to define more and more complex combinations of a subproducts
until you arrive at your final configurable products.

Take for example the two attribute value pairs Color in {red, blue, green}
and Material in {wood, metal}. These could specify a door knob, whereby
not all combinations are possible:

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

You could then define a door as:

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

Interestingly you will not see any logic formula in such a product specification,
only facts and rules, and a lot of parameters passed around. You can use the
parameters in a knowledge acquisition component. By just running uninstantiated
goals you can derive possible values for the attribute value pairs. The predicate
setof/3 will sort and removen duplicates for you:

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

Now you know the range of the attributes and you can let the end-user successively
pick an attribute and a value. Assume he takes the attribute Color and its value blue.
The range of the attribute Material then shrinks accordingly:

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

In the end when all attributes have been specified you can read off the article
numbers of the subproducts. You can use this for price calculation, by adding some
facts that give you additional information on the article numbers, or to generate
ordering lists etc..:

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

Best Regards

P.S.:
Oh it seems that the bill of materials idea used in the product configurator
goes back to Clocksin & Mellish. At least I find a corresponding
comment here:
http://www.amzi.com/manuals/amzi/pro/ref_dcg.htm#DCGBillMaterials

回复收藏 0 原文

~没有更多了~