[Gecode] FW: PowerB

[Christian Schulte]

> >The right architecture should be as follows:
> > 1. The API function does preprocessing on the arguments, creates the
> >appropriate variable arrays to be passed to the propagators proper.
> >    The last point happens automatically when implicitly casting a 
> >IntArgs to VarArray<IntVar>.
> >    Then, a propagator-based (maybe a static method) post-method is 
> >invoked.
> >
> > 2. Then the propagator-based post-method decides what is the right
> >propagtor (typically some appropriate variant) to create.
> >  
> >
> Is there an existing propagator that has such a method?

To some extent the linear propagators do that. But this is rather
complicated. Otherwise, not quite as I said.

> If not, what should be its signature?

Make it a static member of the class called post: return type void,
arguments as required by the propagator.

> public static WhateverPropagator::post(VarArray<IntVar> vars) 

Yes.

> ? You can still check for variable equality on this level, 
> right? So this layer 2. propagator-based post-function (PBPF 
> :-) )  is 
> responsible for instanciating a propagator if it is indeed a 
> subvariant, 
> or call the PBPF of a simpler propagator or one with less 
> arguments if 
> apropriate.
> Right?

Yes.

> > 3. The propagator constructor does the real job of initializing a
> >propagator.
> >
> >Unfortunately, quite often I have combined 2. and 3. This needs to be
> >fixed eventually.
> >  
> >
> I guess I could move all decision logic from plain post functions to 
> PBPFs, and get a good overview of all the propagators?

Right, absolutely!

> >Now getting back to your real question: Typically, you will go for 3.
> >when replacing a propgator. You never go for 1. as you don't want to 
> >create new variable arrays (they are just resued for the 
> newly created 
> >propagator). So, in a fixed system you would also have the choice 
> >between 2. and 3.
> >
> >  
> >
> I'd go with 2 so I don't have to either duplicate its 
> functionality, or 
> loose propagatoin power due to undiscovered variable equalities. And 
> using the most abstract type possible is so cool anyway :-)

Exactly.

> >>3,
> >>How would you "cast" an IntVar into a BoolVar?
> >>My propagator wants to replace itself with a reified
> >>constraint: 0^b=c  <=>  c=(b==0)
> >>
> Guido has told me since:
> #define intvar2boolvar(intvar)  static_cast<BoolVar>(intvar.core())

DON'T! This makes assumptions on object outside methods. That's not C++. And
look's wrong to me.

It is just about a copy conbstructor, along the lines

	explicit BoolVar::BoolVar(IntVar x) { core(x.core()); }

or something similar. The you can use it as

	BoolVar b(x)

where x is an IntVar. Maybe I should add that.


> >>5,
> >>I know this is a stupid question, maybe I just did not sleep
> >>enough: I don't understand why doing ceil/floor on integer
> >>valued floats works.  
> >>Looks like the 100dB amplification of Braun noise to me, but 
> >>I'm just an 
> >>engineer... ;-)
> >>I mean it's pot luck whether floor(ln(4.0)/ln(2.0))  is 1 or 
> >>2, right? 
> >>
> >Yes, might be. But maybe that means you have to resort to exact
> >algorithms
> >(integer-based) for log (ld). Why ln to start with?
> >  
> >
> Dunno, it's probably an EE thing, we do everything theoretic 
> in natural 
> base. Either 'cause it's one letter less, expresses well 
> "it's not the 
> base you want", or easy to derivate :-)
> For practical stuff we use base 10.

Computer scientist use base 2, of course. Reason: exact and fast algorithms.

> 
> 
> This one is still open:
> 
> > 6, Do you have any preference in unit testing
> > frameworks? Anything against CppUnit?

No real opinion yet. CppUnit seems not mature enough. And I have been
thinking more on how to derive tests automatically as this appears a much
harder task... The rest we can do whatever we like.


Cheers
Christian