[gecode-users] FloatVar implementation

[Christian Schulte]

Filip,

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.

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.

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.

Christian

On 4/9/08 3:52 PM, "Filip Konvička" <filip.konvicka at logis.cz> wrote:

> 
>> Hmm, I am not so sure that Guido is telling the truth here ;-) I just had a
>> chat with him and he agrees ;-)
>>   
> I hope I didn't start any fight :-)
>> The kernel only knows about a base class that contains no information
>> whatsoever about how the domain of a variable is implemented.
>> 
>> What is perfectly possible is to have variables of different types in the
>> system that share the same baseclass: the kernel is only concerned with what
>> is in the baseclass and not with how the variables are implemented. The key
>> aspect is that variable implementations are only refered to by propagators
>> and branchings: they statically know the real type so that the right
>> operations are performed, so no need for virtual etc.
>> 
>> Look to the generated baseclass IntVarImpBase and how IntVarImp inherits
>> from it: IntVarImpBase is what the kernel deals with, while IntVarImp is the
>> real implementation of integer variables.
>>   
> I've seen that, but what I need to understand is why you need distinct
> *VarImpBases for Int, Bool, etc., why not just one. The difference I've
> seen in kernel is that the classes report their own "event id" or
> whatever, so I guess you use this for speeding up actor filtering.
> Again, I'm just guessing and will need to look into this.
> 
> [...some time passes...]
> 
> OK, we've added float.vis and recompiled Gecode, so now it seems we have
> our own bunch of ModEvents and also a FloatVarImpBase, which is cool, so
> we'll come back with a status report (or more questions) soon :-)
> 
>> Having said all that, I would first attempt to get everything up for a
>> single implementation. You can go crazy later ;-)
>>   
> I guess I'm crazy enough already - nothing ever stops me from making
> things more generic. Even if it takes 5 minutes to compile... :-))
> 
> Cheers,
> Filip
> 

--
Christian Schulte, web.ict.kth.se/~cschulte/