问题标签 [constraint-handling-rules]

For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.

0 投票
3 回答
119 浏览

prolog - 在 prolog 中解决链式反应

最近出现的代码挑战之一要求我解决最少量的输入材料,我可以使用这些材料来应用一组给定的反应并获得 1 个单位的输出材料。

例如,给定

我们总共需要 31 块矿石来制造 1 种燃料(1 块用来生产单位 B,然后 30 块用来制造必需的 28 A)。

今年,我一直在努力拓展我的编程语言视野,所以我已经完成了 SML/NJ 的大部分挑战。这个似乎——<em>似乎——很适合 Prolog,考虑到我对它的了解很少:逻辑编程、约束求解等。

但是,我无法成功地对约束进行建模。

我首先把这个简单的例子变成了一些事实:

老实说,我什至不确定 list 参数是否是一个好的结构,或者函子表示法 ( ore(10)) 是否是一个好的模型。

然后我想建立允许你说的规则,例如,10 矿石足够 7 a:

这可行1,但我不确定它是否足够,因为我们可能会关心剩菜(毕竟这是一个最小化问题)?

我被困在接下来的两件事情上:

  1. 我可以问是什么使 7 A 得到 10 矿石,但我不能问什么才足够 20 A:我如何编写一个编码乘法/整数因子的规则?
  2. 我可以说 7 A 和 1 E 制造 1 种燃料,但我不能递归地说明这一点:也就是说,我不能说 14 A 和 1 D制造 1 种燃料。如何编写对此进行编码的规则?

我愿意为我提出的事实使用替代数据编码——最终,我将编写从 Advent 的输入到 Prolog 的事实的转换脚本,所以这是我最不担心的。我觉得如果我能让这个小例子工作,我可以解决更大的问题。


  1. ?- makes(X, a(7)).无限回馈X=[ore(10)](即,如果我一直;按提示,它会继续)。有没有办法来解决这个问题?
0 投票
1 回答
80 浏览

prolog - 减少 Prolog 中的约束

最近出现的代码挑战之一要求我解决最少量的输入材料,我可以使用这些材料来应用一组给定的反应并获得 1 个单位的输出材料。

例如,给定

我们总共需要 31 块矿石来制造 1 种燃料(1 块用来生产单位 B,然后 30 块用来制造必需的 28 A)。

今年,我一直在努力拓展我的编程语言视野,所以我已经完成了 SML/NJ 的大部分挑战。这个似乎——<em>似乎——很适合 Prolog,考虑到我对它的了解很少:逻辑编程、约束求解等。

在一些帮助下,我能够整理出一个工作版本,并且我抽出时间阅读了一些关于 CHR 编程的教程。我想我基本上明白,下面,我们说如果我们知道 10 个a(1)项目(这些被称为什么?证明?),那么我们可以将其替换为ore(10)- 将扩展为 10 个单独的ore(1)调用。

不过,如果能够编写以下内容,那就太好了:

并以某种方式告诉 prolog,如果我“知道”,例如,a(8)我仍然可以替换它ore(10)(因为我需要 10 矿石来制造那些 8a,而有些只是浪费了)。

认为如果我能做到这一点,我可以把这个输出

进入

如果我手动添加,ore:a(2)到燃料查询中,我会得到正确的总矿石。

总结一下,

  1. 我如何表达我不能部分运行反应,但我可以运行反应以获得比我需要的更多的约束?换句话说,如果我需要a(8),就足以知道我需要a(10)吗?我认为,这也将允许我用类似的语言a(10) <=> ore(10)而不是荒谬的语言来编写原始问题陈述a(1),a(1)...。还是会?
  2. 这会解决我的“搜索”问题,这样fuel(1)会给我ore:total_ore(31)吗?

更新:我花了一些时间玩(1)来获得

total_ore(41)为我的查询产生了。我相信“剩菜”正在转化为矿石,在这种情况下,这不是我想要的(尽管它当然是指定的)。s现在a被删除得太早了——也就是说,这是正确的,但不是最小的。如何更喜欢整体反应?嗯……

0 投票
1 回答
55 浏览

prolog - 为约束生成分解约束

考虑以下设置:

我知道 prolog 能够进行元编程,并且我相信它可以用来生成x(X)上面的分解,但我完全不知道该怎么做。我曾经很接近=..用来拆开并重新组合电话,但后来我不得不在n(a(2))任何地方写一些东西。理想情况下,我会写n(a)一次并添加正确的约束规则(断言?):

能够做类似的事情会更有意义

如果它是 lisp,我想我可以编写宏来做到这一点。prolog 应该是和 lisp 一样的谐音,所以理论上是可以实现的。我只是不知道怎么做。

如何按照类似于上述风格的方式编写分解器“宏”?

0 投票
0 回答
85 浏览

prolog - SWI Prolog 中的 CHR:包含“刚刚删除”约束的规则保护不返回,破坏堆栈

一点没有特别含义的测试代码:

如果从 SWI Prolog 命令行查询上述内容,然后运行:

一段时间后溢出:

但是,如果通过将测试bar从守卫移到头部来更改第二条规则的代码:

然后执行终止:

这是实施的意外吗?这似乎有点冒险。

此外,编写上述代码是因为我想测试要从存储中删除的约束(此处为bar(Y))是否在规则主体中可用。显然不是,在规则体执行时它已经消失了;但是这个实现是依赖于 CHR 的还是必要的或指定的行为?

0 投票
0 回答
32 浏览

prolog - 有没有办法在运行时在 prolog 中重新排序 CHR 规则?

我在 Prolog 中为艺术目的编写程序,严重依赖大量 CHR 规则。我希望能够运行多次,但每次产生不同的输出。最简单的方法是每次都不确定地重新排序约束。

例如,对于一首诗的形式,我可能想要一个 ABAB 或 ABAC 形式。然后我想写:

我希望第一条规则有时会在stanza出现时触发,而第二条规则有时会触发。我怎么能用 CHR 做到这一点?

0 投票
1 回答
129 浏览

javascript - tau-prolog 不会运行我使用 CHR 库的 prolog 代码,尽管它适用于 SWI-Prolog

我正在尝试使用 Tau Prolog 运行 CHR 代码,它给出了这个错误:

虽然它在 SWI Prolog 上运行良好。

这是序言代码:

这是我运行的查询:

这是我用来运行 Tau Prolog 的 JS 代码:

0 投票
1 回答
61 浏览

prolog - SWI Prolog 中的约束处理规则:对 store 施加约束的顺序是什么?

我正在学习swi-prolog 中的约束处理规则 (CHR)

我从 Tom Schrijvers 的Constraint Handling RulesA Tutorial for (Prolog) Programmers的教程开始。

令人困惑的是,将约束放入约束存储的顺序是什么?

  1. p.69 显示当规则触发时,将正文添加到(前面)查询。

  2. p.104 - p.106 表明,通常情况下,对 store 施加约束的顺序遵循查询顺序。也就是说,第二个约束 ( piggy(1)) 将放置在piggy(5)商店中第一个约束 ( ) 的右侧。

  3. p.107,根据1,piggy(6)添加到查询前面,然后放入商店。

  4. p.108,奇怪的事情发生了,为什么piggy(4)要放在商店前面(左到piggy(6))?

  5. p.109 - p.110,更奇怪的是,规则触发后,piggy(10)被添加到商店,然后piggy(2)被添加到商店的末尾(有权piggy(10))?

我的第一个问题是将约束放入约束存储的确切顺序是什么?

例如,

为什么 swi-prolog 中的查询结果是:

代替

慢动作是(在我的理解):

似乎当触发规则时,应该将正文添加到(结束)查询?那正确吗?

我的第二个问题是订单敏感?

我的意思是即使下单不同,结果最终会汇合到重新订购稳定的商店?我可以放心地忽略此命令吗?我知道在 swi-prolog 的 CHR 实现中,规则的顺序非常敏感,不能忽略。

谢谢。

0 投票
2 回答
60 浏览

prolog - SWI Prolog 中的约束处理规则:`neq` 约束不起作用

我正在学习 swi-prolog 中的约束处理规则 (CHR)。

我从 Tom Schrijvers 的Constraint Handling Rules A Tutorial for (Prolog) Programmers的教程开始。

在p.286中,作者给出了一个实现不等式约束的例子。

但它在 swi-prolog 中没有按预期工作。

例如,在 swi-prolog

但应该是

如何获得与幻灯片中相同的结果?

我在 Windows 上的 swi-prolog 版本(线程,64 位,版本 8.2.4)。

谢谢。