On 08-05-14 14:38, dBijkoo wrote: > ge0ffrey wrote >> In OptaPlanner's architecture current philosophy, this is not legal: >> a value range should be stable for each variable (of each entity) during >> solving. >> This not guaranteed to work (and it is guaranteed not to work if you do >> phase caching of moves: >> it will invalidly exclude part of the search space). > So if I understand you correctly phase caching moves is the way to go? No Phase caching moves is definitely NOT the way to go :) Phase caching means it caches as moves at the beginning of the solver phase. So as some variables change value in steps, the possible move set doesn't.
> > > ge0ffrey wrote >> If it does work for you, I am interested to know more about this - so I >> can consider to make this approach legal. > It is working for me, to give you a better impression of my approach i added > an image of my "planning classdiagram". > <http://drools.46999.n3.nabble.com/file/n4029484/Planning_class_diagram.png> > Observation contains 2 annotated planningVariables getScheduleBlock() and > getPeriod(). in the getPeriod() function it checks if the scheduleBlock is > not null, if so it uses scheduleBlock.getPlanningsPeriods() function to > return a list of periods. I believe this approach will hit the wall when you try to add a move that changes the 2 variables of an entity in a single move. Side note: To do this, you can configure a <cartesianProductMoveSelector> of 2 <changeMoveSelector> for which the second has an <entitySelector> that mimics the first one's. IIRC, the course timetabling example has such a config example. What will happen is that it will select a variable for the period from the range of the Observation's old block and meanwhile also change the block. There's a number of features this approach won't allow you to do (and I might not recall all of them). Because I want to solve this problem, without limiting so many features, I want to solve it differently in the future. > > If have any more questions feel free to ask, we are all working to make > OptaPlanner better. +1 yes, definitely :) I understand the need for this problem, and why the current recommended solution is suboptimal (to large search space). Feel free to make a jira for the problem (not your proposed solution). > I can even send you a zip of my current code if you are > interested. My time is too limited to review code zips (unless it's a reproducer for an accepted bug). Anyway, what is the recommended solution? Not sure. A) Either just allow all combinations, that will work. B) Or try @Entity class Observation { @Variable block; } @Entity class Block { @Variable("periodRange) period; @VariableProvider("periodRange") getPeriodRange(); } Not sure if this matches for your case - multiple Observations might share the same Block for a different period... This is allowed - (it's called ValueRange from planning entity) and more deeply supported (although it does have a few limits too). C) Or try class BlockPeriod { Block; Period; } @Entity class Observation { @Variable BlockPeriod; } Hmm. I like alternative C! > > > > -- > View this message in context: > http://drools.46999.n3.nabble.com/rules-users-Drools-Planner-what-if-possible-values-of-a-PlanningVariable-are-dependent-of-another-on-tp4021175p4029484.html > Sent from the Drools: User forum mailing list archive at Nabble.com. > _______________________________________________ > rules-users mailing list > rules-users@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users > _______________________________________________ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
