struggling with syntax and semantics, need help with code

[Raphael Collet]

George Rudolph wrote:
> 2. Clearly, though, I have problems understanding the difference between 
> "=" and"=:", and "==" and ":=". I still am not clear when one or the 
> other, in each respective case, is required, and what the semantics are.

I see.  Here is an explanation:

  - The statement X=Y unifies X and Y (variables or values).  This
    performs the necessary variable bindings in order to make both sides
    equal.  It never blocks, except if read-onlys must be bound.

  - The expression X==Y returns "true" if X and Y are equal, "false" if
    they are different, and blocks otherwise.

  - The statement X+Y=:Z stands for {FD.sumC [1 1 ~1] [X Y Z] '=:' 0}.
    It posts a propagator for the equation.  The same holds for "<:",
    and other similar operators.  They are syntactic sugar for FD.sum,
    FD.sumC, or FD.sumCN.

    But when used as an *expression*, it reifies the constraint!  For
    instance B=(X<:Y) stands for {FD.reified.sumC [1 ~1] [X Y] '<:' 0 B},
    where B is a binary constrained variable (domain 0#1).  The 'value'
    of X<:Y is thus a 0#1-variable, and neither "true" nor "false".

  - ":=" is a cell/array/dictionary assignment operator.  If C is a cell,
    then C:=42 is the same as {Assign C 42}.  This is imperative-style
    assignment, and has nothing to do with constraint programming.

Does it clarify a bit?

> 3. In some iteration of writing that code, I tried using the Mod or ModI 
> operator in just that way, and it didn't seem to work--probably that was 
> because of other problems with the script, though.  But I eliminated 
> that possibility by writing what I thought was equivalent code for it.
> 
> What do you mean that the condition Z <: 93 is not a boolean condition?
> What type is returned by that expression?

The statement Z<:93 constrain Z to be smaller than 93.  The expression 
Z<:93 returns a constrained variable (say B) which is constrained by the 
logic formula:

	B belongs to {0,1}   and   (B=1 iff Z<93)

> 6.  I like this following fragment. In the code I posted, I knew I didn't
>     really want those conditionals, I wanted a uniform constraint--but
>     I couldn't figure out how to state it.  Here, you did it!
>  
>       %% The number of X such that Intersect0Y.X==1 is equal to
>       %% Count.Y+21 (22 if Y in D, 23 if Y in E).
>       {FD.sum Intersect0Y '=:' {FD.plus 21 Count.Y}}

Once you get used to it, you smell this kind of tricks in your problems. 
  Exploiting them can greatly improve a solver.

> 7. Clearly, this new constraint on the pairs is what makes the problem 
> both combinatorial, and potentially intractable for large V (i.e. V = 93).
> 
> Apparently even when we can reduce it to looking at pairs {0,Y}, as 
> opposed to all pairs {X,Y}.
> 
> However, consider this: It should now be relatively easy to constrain 
> the search space further by asking for solutions that contain specific 
> blocks, or (sub)sets of blocks, or to further constrain values of X 
> and/or Y.  Correct?
> 
> That would yield one or more valid solutions in a smaller search space, 
> not enumerating every possible solution, but finding some, if they exist.
> 
> And therefore getting a further glimpse into the structure of the 
> solution space.
> 
> This is, I think, one of the strengths of a CLP approach as opposed to 
> other methods such as Combinatorial Optimization algorithms:  The 
> ability to add (or remove) recognizable constraints to tune the solver.

I don't know exactly what you have in mind, but that's certainly worth 
having a look at it.  An issue with the problem is the number of 
solutions.  Every trick that reduces the set of solutions to a smaller 
set that is representative of all solutions, is worth the pain.

> 8. I knew that the algorithm I posted was "heavy", as you say, I was 
> focused on trying to put together something that would work correctly, 
> and then strive to make it more efficient.  I have been trying to learn 
> the language of constraints in Oz, as well as discover hidden structures 
> and properties in this class of design problems, on top of developing an 
> executable specification of this particular problem (where V=93). I plan 
> to generalize the code to work with any V that fits the more general 
> design problem, much like the Steiner Triple solver will work with any N 
> that meets the basic constraints on N--but I want to do that only after 
> the code works for the current case.

Good luck!  Keep us informed, and don't hesitate to ask questions when 
something looks obscure to you.

Cheers,
raph