Dear Russ,
I think I have to second Raphael here: you seem to misunderstand the
Oz-way (in contrast to the Prolog way that is). In Prolog, search is
implicit. Do don't explicitly call a solver and any Prolog program
potentially performs a search. In Oz, search is only performed when the
users asks for it by handing a script to a solver. That way, the user
can control which parts of the program perform a search and which
don't.
The =/3 operator you asked has to be defined such that it may require
search. Any of its arguments is potentially undetermined and there may
be multiple solutions. The constraint UnifyR is defined accordingly.
proc {UnifyR X Y B}
B = {Combinator.'reify' proc {$} X = Y end}
end
On 05.10.2005, at 23:05, Russ Abbott wrote:
When I called UnifyR as a top-level program, it suspended.
Section 5.10 of the System Modules documentation says that reified
propagators wait in the same way as their non-reified counterparts.
Most constraint propagators require constrained variables as arguments
(i.e. variables with a domain such as FD ints or FS vars). This is what
the doc sentence you quoted refers to (see Sec 3.2 of System Modules
for details).
However, UnifyR also works with free variables (i.e. completely
undetermined variables). Therefore, UnifyR does never suspend: you may
not have seen immediately what it does if you called it with multiple
undetermined variables.
Like any other propagator, UnifyR can be called in the top-level as
well. A propagator by itself does not need search. Actually, calling a
propagator in the top-level can be very instructive as it shows you
constraint propagation in action. A propagator will not decide for
anything, but only deduce what can already be known without excluding
any solution. Only search will decide for alternatives. However, when
you specify enough information, a constraint propagator will indeed
determine its arguments without any search.
For instance, you may call UnifyR like a plain boolean function (e.g.
the equality check ==)
{UnifyR foo bar}
which returns 0 (i.e. false). Actually, what happens here is that the
returned value is first a FD int which is then concurrently determined
0 by the propagator.
Furthermore, you may call
{UnifyR foo X 1}
which determines X to 'foo'.
However, like any other propagator UnifyR does not necessarily fully
determine its arguments. For instance, the call
declare X Y
{UnifyR X Y 1}
only unifies X and Y without determining either.
Similarily,
declare X Y B
{UnifyR X Y B}
constraints that X and Y are unified iff B=1 and X and Y are not
unified otherwise.
Best,
Torsten
On 05.10.2005, at 23:05, Russ Abbott wrote:
Thanks, Torsten. I gather that this can be used only inside a
constraint problem. When I called it as a top-level program, it
suspended.
Section 5.10 of the System Modules documentation says that reified
propagators wait in the same way as their non-reified counterparts. My
guess is that this implies that this and all other propagators are not
intended to be executed directly but are used when solving FD
problems.
In my most recent previous message, I suggested that perhaps one
should think of Oz primarily as a way of expressing constraints. In
that context, using reify makes sense. My original version of Unify
was intended to be used in non-FD contexts as well. But that probably
isn't something that one should ask for since that isn't Oz's primary
use.
-- Russ
On 10/5/05, Torsten Anders <[EMAIL PROTECTED]> wrote:
Dear Russ,
Here is an alternative definition of =/3. {UnifyR X Y B} has the
desired semantics B <-> (X = Y).
proc {UnifyR X Y B}
B = {Combinator.'reify' proc {$} X = Y end}
end
Here, unification is defined as a reified constraint: X and Y are
arbitrary values and the 'boolean' value B is an 0/1-integer, i.e. a FD
with the domain 0#1 where 0 represents false and 1 represents true.
(The advantage of this representation for a boolean is that you can
apply arbitrary further FD-int constraints to it. For example, you may
FD.sum a number of 0/1-ints to constrain how many of them are true.
See
the docs for more information on reified constraints, e.g., the FD
constraints tutorial).
Combinator.'reify' expects a nullary procedure as argument and
constraints B according whether the body of the procedure is entailed
or not.
Best,
Torsten
--
Torsten Anders
Sonic Arts Research Centre
Queen's University Belfast (UK)
www.torsten-anders.de
On 05.10.2005, at 21:05, Russ Abbott wrote:
> I'm confused. My message wasn't talking about backtracking. It only
> suggested that it would be useful to define a =/3, which returned
true
> or false as a value depending on whether its first two argument could
> be unified. As a side effect,it would unify those first two arguments
> if possible. Since =/2 is defined as part of the base language, this
> would not require anything new. It could be defined easily as in my
> example.
>
> -- Russ
>
>
> On 10/5/05, Raphael Collet <[EMAIL PROTECTED] > wrote:
> Russ Abbott wrote:
> > Define a proc Unify/3 that attempts to unify its first two
arguments
> and
> > sets its third argument to true/false depending on whether not it
> succeeds.
> >
> > local
> >proc {Unify X Y Z}
> > try X = Y Z = true
> > catch _ then Z = false
> > end
> >end
> >A B
> > in
> >if {Unify [A b a] [a B B]} then {Browse 1#A#B}
> >elseif {Unify [A b] [a B]} then {Browse 2#A#B}
> >end
> > end
> >
> > It would be even nicer if value.'=' were defined as both =/2 and
=/3,
> > with the latter being defined as above.
>
> Sorry, the logic part of Oz is not an inclusion of Prolog.Unification
> and testing for equality are distinct in Oz.The base model of Oz
> (concurrent constraints) requires to distinguish between both.
>
> The statement X=Y tells the constraint X=Y to the store, while X==Y
> asks
> whether the store entails X=Y.The latter blocks if the constraint
> store does not contain enough information.
>
> This behavior combines very naturally with concurrency.Testing
> equality cannot tell extra constraints to the store (like Prolog
> would).
> A "speculative" unification is problematic, because backtracking one
> thread would require to backtrack all threads in the system.That is
> unreasonable to implement.
>
> Cheers,
> raph
>
>
_______________________________________________________________________
> __________
> mozart-users mailing list
> [email protected]
> http://www.mozart-oz.org/mailman/listinfo/mozart-users
>
_______________________________________________________________________
> __________
> mozart-users mailing list
> [email protected]
> http://www.mozart-oz.org/mailman/listinfo/mozart-users
_______________________________________________________________________
__________
mozart-users mailing list
[email protected]
http://www.mozart-oz.org/mailman/listinfo/mozart-users
_______________________________________________________________________
__________
mozart-users mailing list
[email protected]
http://www.mozart-oz.org/mailman/listinfo/mozart-users
--
Torsten Anders
Sonic Arts Research Centre
Queen's University Belfast (UK)
www.torsten-anders.de
_________________________________________________________________________________
mozart-users mailing list
[email protected]
http://www.mozart-oz.org/mailman/listinfo/mozart-users
