Hi David, I just checked the code for minus_r and I was a little surprised: I just forgot to add the detection of this special case for minus_r, the other iterator-based variable operations check for special cases (precisely to get a more accurate delta). I'll jot it down to my list and it should be in 3.0.0 as it is not hard (Mikael, sorry for contradicting you here ;-) ).
Cheers Christian -- Christian Schulte, www.ict.kth.se/~cschulte/ -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Mikael Zayenz Lagerkvist Sent: Wednesday, January 21, 2009 3:48 PM To: David Rijsman Cc: [email protected] Subject: Re: [gecode-users] Any Advise on Delta 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 <[email protected]> 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 > [email protected] > https://www.gecode.org/mailman/listinfo/gecode-users > -- Mikael Zayenz Lagerkvist, http://www.ict.kth.se/~zayenz/ _______________________________________________ Gecode users mailing list [email protected] https://www.gecode.org/mailman/listinfo/gecode-users _______________________________________________ Gecode users mailing list [email protected] https://www.gecode.org/mailman/listinfo/gecode-users
