Hi,
In the case of cumulatives, the domain information could be reported
in a better way since singleton ranges are removed, mapping naturally
onto the integer delta abstraction. Unfortunately, this would
complicate the code for the minus_r operation, and thus it is not
clear that we will do it.
If your interest is to check if the upper bound of a variable has
changed, then caching the maximum value in the advisor is simple and
rather efficient. This is probably what I would do, and it is
independent of the delta-information that is computed.
Cheers,
Mikael
On Wed, Jan 21, 2009 at 2:38 PM, David Rijsman
<david.rijs...@quintiq.com> wrote:
> Christian,
>
> in a previous conversation on 'Any Advise on assignment delta' you mentioned
> "the other operations that lead to 'any' are iterator-based variable domain
> updates which in most cases just remove a single value or a range (and hence
> the delta information is accurate).". Concerning this I have the following
> question:
>
> I have been implementing a propagator which implements its own advise method.
> The intention of the advise method is to only schedule the invoking
> propagator if the maximum has changed. This is relatively easy to implement
> but I noticed that the 'delta' reporting is rather 'rough' implemented and my
> propagator gets scheduled quite often to conclude nothing. That is I am
> getting a lot of 'any' hits when there could have been more information.
> Specifically in my use case I have a cumulatives constraint whose propagator
> uses View::minus_r a lot and this propagator only reports 'any' deltas (as
> far as I can conclude). In the example in this e-mail clearly shows we could
> be more informative in the delta, it streams 1-0 (any) although I would
> expect 0-50.
>
> My question is if this is done for a reason and if so if this is done for
> many operators on the views?
>
> //----------------------------------
>
> #include "gecode/kernel.hh"
> #include "gecode/int.hh"
> #include "gecode/iter.hh"
>
> namespace Gecode
> {
> class MyPropagator : public Propagator
> {
> public:
> MyPropagator(Space *home, Int::IntView v):
> Propagator(home),
> MView(v)
> {
> MView.subscribe(home, new (home)
> ViewAdvisor<Int::IntView>(home,this,MCouncil,MView));
> }
>
> MyPropagator* copy (Space* home, bool share)
> {
> return 0;
> }
>
> ExecStatus propagate(Space *home, ModEventDelta med)
> {
> return ES_OK;
> }
>
> PropCost cost (ModEventDelta med) const
> {
> return PC_LINEAR_LO;
> }
>
> ExecStatus advise (Space *home, Advisor *a, const Delta *d)
> {
> ViewAdvisor<Int::IntView>& advisor =
> static_cast<ViewAdvisor<Int::IntView>&>(*a);
>
> std::cout << advisor.view().min(d) << "-" << advisor.view().max(d) <<
> std::endl;
>
> return ES_OK;
> }
> private:
> Int::IntView MView;
> Council<ViewAdvisor<Int::IntView>> MCouncil;
> };
>
> class MySpace : public Space
> {
> public:
> MySpace()
> {
> MX.init(this,0,100);
>
> }
>
> MySpace(bool share, MySpace &s):
> Space(share,s)
> {
> MX.update(this,share,s.MX);
> }
>
> MySpace* copy(bool share)
> {
> return new MySpace(share, *this);
> }
>
> IntVar MX;
> };
> }
>
> int main()
> {
> Gecode::MySpace space;
>
> new (&space) Gecode::MyPropagator(&space,space.MX);
>
> Gecode::Int::IntView view(space.MX);
>
> Gecode::Iter::Ranges::Singleton d(0,50);
>
> view.minus_r(&space,d,false);
> }
>
> //----------------------------------
>
> David
>
> Quintiq Conference "Quintessence 09" Tuesday May 12th, 2009, Country Estate
> Duin & Kruidberg, near Amsterdam Schiphol, The Netherlands - for more
> information visit www.quintiq.com
>
> This message contains information that may be privileged or confidential and
> is the property of Quintiq. It is only intended for the person to whom it is
> addressed. If you are not the intended recipient, you are not authorized to
> read, print, retain, copy, disseminate, distribute or use this message or any
> part thereof. If you have received this message in error, please notify the
> sender immediately and delete all copies of this message. Please note that
> e-mails are susceptible to change, therefore they are not binding.
>
> _______________________________________________
> Gecode users mailing list
> us...@gecode.org
> https://www.gecode.org/mailman/listinfo/gecode-users
>
--
Mikael Zayenz Lagerkvist, http://www.ict.kth.se/~zayenz/
_______________________________________________
Gecode users mailing list
us...@gecode.org
https://www.gecode.org/mailman/listinfo/gecode-users
