[gecode-users] FloatVar implementation

[Filip Konvička]

> Yes, that's true and has always been the case (more or less). It used to be
> that one had to have a reserved identifier known by the kernel.
> 
> Then, in the end we decided it does not make a difference in practice and
> just include the stubs for variable types into the kernel. Note it is just
> type information about stubs, no information about how variables are
> implemented go into the kernel.
> 
> One, of course, could do a dynamic architecture. But's just painful will
> degrade performance and is not very useful: the number of different variable
> types will be pretty limited.
> 
> The only thing that is a little odd, is that the specification file from
> which the stubs are generated must be mentioned in the variables.vsl file.
> But cleaning this up we can do if you decide to either contribute your code
> to Gecode directly (;-), so it can just be listed there) or as a separate
> contribution. Please get in touch with us then and we revive the contribs
> configuration again.

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

But I'm afraid that I'm guessing too much here, I really need to look 
into the kernel...

Cheers,
Filip