FD

[Luis Quesada]

Denys Duchier wrote:

>
> The reason the following infers a contradiction ...
>
> > local
> >    A={FD.decl}
> >    B={FD.decl}
> > in
> >    A=:B
> >    A\=:B
> > end
>
> ... is that A=:B unifies A and B and then A\=:B is a run at least once
> and realizes that the the constraint is necessarily disentailed.
>
> The reason the following doesn't make the same inference ...
>
> > local
> >    A={FD.decl}
> >    B={FD.decl}
> > in
> >    A\=:B
> >    A=:B
> > end
>
> ... is that the propagator for \=: is defined to only wake up when one
> of its parameters becomes determined.  Thus it is not woken up when
> A=:B unifies A and B.  This is of course wrong since A\=:B should
> become entailed as soon as the domains of A and B are disjoint.
>
>

Actually, I would like to know  more about the algorithm that is being used
to handle inequalities over finite domain variables. For instance, is the
current algorithm more efficient than building an enumerated types
constraint system [*] on top of the FD constraint system?

Is the current algorithm more complete? For instance, I would like to see
*ok* in the browser in the following case:

local
   A={FD.decl}
   B={FD.decl}
in
   A\=:B
   cond A\=:B then {Browse ok} end
end

as it happens in this case (even thought the variable are not determinate):

local
   A={FD.decl}
   B={FD.decl}
in
   A=:B
   cond A=:B then {Browse ok} end
end


Luis

[*] Saraswat, V. Concurrent Constraint Programming. (Section 2.4.1, page
54)


--
Catholic University of Louvain
Department of Computing Science and Engineering
Place Sainte Barbe, 2
B-1348 Louvain-la-Neuve, Belgium
Phone: (++32) (10) 47 90 13
Fax: (++32) (10) 45 03 45
E-mail: luque at info.ucl.ac.be



-
Please send submissions to hackers at mozart-oz.org
and administriva mail to hackers-request at mozart-oz.org.
The Mozart Oz web site is at http://www.mozart-oz.org/.