[gecode-users] FloatVar implementation

[Christian Schulte]

What you intend to do sounds very reasonable.

As it comes to integration versus contribution: we would wish integration
but we might have to settle for contribution. We can or want to integrate
only if:
 - The code is not tainted by a too restricted license, so only MIT.
 - The code is of high quality such that it is well tested, well
   documented, useful for many people, and realistic as it comes to
   performance. We will not integrate code that we can not fix or port
   ourselves.
 - The code must be portable and conform to the C++ standard.

I believe that you should make it for all three criteria. But let's see. We
can first go for contribution and later promote to integration.

Cheers
Christian

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

> 
>> 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
> 

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