[gecode-users] FloatVar implementation

[Filip Konvička]

> If you check the stubs for all the different variable types you will see
> that there are two aspects in which they differ. Both of which depend on the
> variable implementation specification you deliver:
>
>  - Propagation conditions: a stub class allocates one slot for each
>    propagation condition you specify. This is used to find all propagators
>    with a particular propagation condition.
>
>    As cloning is controlled by the kernel, the kernel needs to know
>    how many slots a variable has so that all of its slots are copied.
>
>  - Modification events: a modification event on a variable determines
>    what are the propagators that must be propagated. For example, for
>    integer variables, if the the min or max of a variable changes, this
>    results in a ME_INT_BND modification event (one of the bounds changed).
>    The specification contains the information that all propagators
>    for that variable with conditions PC_INT_DOM (run if anything changes)
>    and PC_INT_BND (run if the bounds change) must be run.
>
>    The code that runs (actually schedules propagators for later execution)
>    is generated from the specification as, again, this is done in the
>    kernel. Moreover, the code is super optimized (really with number
>    of assembly instructions in mind) as it is at the core of the kernel.
>
> There is one more thing that happens (computing an optimal bit layout for
> modification event deltas) but I won't go into that.
>   
I see. No problem, as I said, we already added float.vis to generate 
this stuff into the kernel. As I understand it, if we later choose to 
use the specs for multiple variable implementations, they'll share some 
behavior, like - as you describe - modification event triggering 
specific kinds of propagators. But IMHO that should be of little concern 
since a FloatVar is still a FloatVar regardless of the internal domain 
representation.

(This makes me believe we could even use IntVarImplBase & Int ModEvents 
for floats if we find out that they share these properties.)
> So you see, generating the stuff is somewhat less powerful (you need to
> recompile) but has a great return if investment as it comes to speed.
>   
I agree, after all I've done a consistency engine for my runtime system 
so I do appreciate your compile-time efforts. (And I thought that I'd 
never use topological sort in real life!)
> Moreover, a kernel that has been compiled with a particular variable type
> enabled can still be used without linking your programs to code that
> implements the variable proper.
>   
My intention is releasing our implementation as a part of Gecode or as a 
contribution, depending on what you like more. (I'll have to get an 
approval for this but I think I'll get it.) Our current plan is to do a 
template FloatVar and an identity view, a template FloatVarImp 
parametrized by domain representation, provide an implementation of 
FloatVarImp for Boost.Interval, and some basic arithmetic propagators 
(add, mul, min, max, relational, reified relational).

Christian, thanks for all the information, it's very helpful. And the 
code we've been dealing with is all documented very well, nice work!

Cheers,
Filip