[gecode-users] FloatVar implementation

[Christian Schulte]

Hmm, I am not so sure that Guido is telling the truth here ;-) I just had a
chat with him and he agrees ;-)

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.

Having said all that, I would first attempt to get everything up for a
single implementation. You can go crazy later ;-)

Cheers
Christian

On 4/9/08 2:28 PM, "Guido Tack" <tack at ps.uni-sb.de> wrote:

> Filip Konvička wrote:
> I'll have to take a closer look at what kernel
> actually does with  
> these.
> But our implementation, already in its current
> state, can generate
> multiple variable classes. For example, one may choose
> to use either
> boost::numeric::interval<float> or
> boost::numeric::interval<double>  
> (or
> even <long double>) - and the
> domain implementation code will be  
> reused.
>
> Similarly, I think that
> many views and constraints can be generic. If
> the implementation is designed
> carefully, it should be quite  
> independent
> on whether we use
> boost.interval or whatever else.
>
> But when we let the users instantiate
> their own FloatVars by supplying
> their FP-arithmetics library of choice, we
> don't have the variable  
> type
> in advance and can't expose it to the
> kernel at Gecode compile time.  
> Or
> can we? Is it sufficient that all the
> variables have a common base
> class? (Even with the restriction that there is
> just one instantiation
> of FloatVar in a program?)

The kernel only needs to
> know about the modification events and  
propagation conditions for a variable
> type.  You could therefore add a  
generic FloatVar to the kernel, and let the
> user decide which domain  
representation to use (as long as the domain
> representation has no  
impact on the kind of events that are needed).
> However, this assumes  
that the resulting system always only uses a single
> instance of  
FloatVar (you can't mix e.g. variables based on float and
> double).

Cheers,
 Guido


_______________________________________________
Gec
> ode users mailing
> list
users at gecode.org
https://www.gecode.org/mailman/listinfo/gecode-users


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