[rules-users] Drools Planner: what if possible values of a PlanningVariable are dependent of another one?

[Geoffrey De Smet]

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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>