序言:foreach或forall用于约束求解? [英] Prolog: foreach or forall for constraint solving?

问题描述

我正在尝试使用SWI prolog和CLP进行项目调度.我设法支持顺序依存关系，但是我在努力避免重复预订.

I'm attempting project scheduling with SWI prolog and CLP. I managed to support sequential dependencies but I'm struggling with avoiding double booking people.

我有一个称为Schedule的列表，其中包含[taskname，starttime]之类的元素，其中starttime是约束求解器的自由变量.它们已经受到顺序依赖的约束.

I have a list called Schedule containing elements like [taskname, starttime] where starttime is a free variable for the constraint solver. They're already constrained by sequential dependencies.

我正在尝试编写这样的循环以排除重复预订:

I'm trying to write a loop like this to rule out double bookings:

  forall /* or maybe foreach*/ (isa(P,person), (
    % Filter scheduled tasks on that person...
    include(\[T,S]^(assigned(T,P)), Schedule, HisSchedule),
    % Present what serialized expects..
    maplist(\[T,S]^S^true, HisSchedule, Sts),
    % duration is just user-defined data... 
    maplist(\[T,S]^D^(duration(T,D)), HisSchedule, Dus),
    % Hit it...
    serialized(Sts, Dus)
  )),

有了foreach，它总是失败，而有了forall，它总是成功而没有任何约束.

With foreach it always fails and with forall it always succeeds without constraining anything.

就此循环而言，时间表是全局的，其目的是使用序列化来约束其开始时间元素. OTOH，HisSchedule，Sts和Dus取决于特定的人.所以我认为我需要让each使Schedule开心，但又需要让HisSchedule等开心.那是问题吗?如果可以的话，我该如何解决?

Schedule is global as far as this loop is concerned, and the purpose is to constrain its starttime elements using serialized. OTOH, HisSchedule, Sts and Dus depend on the particular person. So I think I need foreach to make Schedule happy but forall to make HisSchedule etc happy. Is that the problem? And if so how do I fix it?

推荐答案

forall/2内置由某些Prolog系统提供，它严重依赖于非单调构造，并且从未设计为与约束协作.尝试变得更聪明的foreach/2也是一样.

The forall/2 built-in is offered by some Prolog systems, it relies heavily on non-monotonic constructs, and was never designed to collaborate with constraints. Same is true for foreach/2 which attempts to be a bit smarter.

那么，这里最大的根本问题是什么?当约束条件尚未广为人知时，许多Prolog都采用了目前的格式.因此，许多构想将目标的成功作为是"作为最终真理.但是，由于受到限制，情况有所不同.一个成功的目标会产生一个 answer ，现在可能根本没有解决方案！因此，成功不再是过去.这是使用SICStus的示例:

So, what is the big, fundamental problem here? A lot of Prolog received its current form when constraints were not widely known. Many constructs thus take success of a goal as a yes as ultimate truth. But with constraints, things are a bit different. A succeeding goal produces an answer which now may contain no solution at all! For this reason success is not what it used to be. Here is an example using SICStus:

| ?- asserta(clpfd:full_answer).
yes
| ?- X mod 2 #= 1.
clpfd:(X mod 2#=1),
X in inf..sup ? 
yes
| ?- X mod 2 #= 1, X mod 2 #= 0.
clpfd:(X mod 2#=0),
clpfd:(X mod 2#=1),
X in inf..sup ? ;
no
| ?- X mod 2 #= 1, X mod 2 #= 0, X in 0..9.
no

答案现在可能根本不包含任何解决方案，换句话说，答案可能是错误的.

Answers may now contain no solution at all, in other words, they may be false.

在您的示例中，include/3和forall/2都存在严重问题.嗯，setof/3也因约束而发疯:

In your example include/3 is highly problematic, as is forall/2. Ah, and also setof/3 gets crazy with constraints:

| ?- setof(t, (I in 1..3 ; I in 3..5 ), _). % SICStus
yes

?- setof(t, (I in 1..3 ; I in 3..5 ),_).  % SWI
I = 3.

如果完全正确，答案是I in 1..5.

要解决此问题，请先将关系数据转换为列表:

To solve this problem, first transform the relational data into lists:

   ...,
   setof(P, isa(P, person), Ps),
   maplist(perperson(P,Global),Ps),
   ...

这篇关于序言:foreach或forall用于约束求解?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！