10:25 p.m.
Hi All,
I have a PlanningEntity that has several planning variables, say A and
B. Now, if A is O then B can be X or Y and when A is P then B can be Y or Z.
I see two routes:
* create a solution property that generates X, Y and Z as alternatives
for B and rely on the score rules to dismiss improper values,
depending on the value of A
* create an entity property that only generates the possible values
for B (i.e. X,Y for A=O and Y,Z for A=P)
What is the best route?
(Alternatively I do not use the constructionHeuristic and just start of
my solution with a randomly (but correct) generated solution)
Regards,
Willem
5:57 p.m.
Op 11-12-12 22:25, Willem van Asperen schreef:
(Alternatively I do not use the constructionHeuristic and just start
of my solution with a randomly (but correct) generated solution)
It could take tabu
search minutes to recover from that.
Any reason you're not using constructionHeuristics?
For 6.0 I am working on making them more scalability and configurable.
10:08 a.m.
Im dealing with the almost the same problem as the original poster. The only
difference is that the subset of entity specific variables and the total
amount of possible variables spread over all entity specific variables has a
factor of up to 24 in between them. This combined with the amount of enities
makes it a huge increase in total amount of possibilities. This gives me the
feeling that using the evaluation class wastes a lot of time evaluation
solution which would never be viable.
Since the original post is 1 and a half years old and a lot of new versions
have been released since then, I was wondering if the same solution applies
to my problem aswell and how it compares to my solution which i described
below.
At the moment i solved it as follows:
PlanningEntity A has the following @PlanningVariable annotation
a class x where the @ValueRangeProvider of x is provided by the
@PlanningSolution annotated class.
a class y where the @ValueRangeProvider uses x to provide the subset of
classes y if x is not null, otherwise it returns an empty list<Y> (code
below)
@ValueRangeProvider(id = "timePeriods")
public List<Period> getTimePeriods(){
ScheduleBlock s = getScheduleBlock();
if(s == null) {
return new ArrayList<Period>();
}
return getScheduleBlock().getTimePeriods();
}
This feels like a hack/workaround for the problem but feel free to let me
know what you think,
Thanks
--
View this message in context:
http://drools.46999.n3.nabble.com/rules-users-Drools-Planner-what-if-poss...
Sent from the Drools: User forum mailing list archive at Nabble.com.
2 p.m.
On 08-05-14 10:08, dBijkoo wrote:
Im dealing with the almost the same problem as the original poster.
The only
difference is that the subset of entity specific variables and the total
amount of possible variables spread over all entity specific variables has a
factor of up to 24 in between them. This combined with the amount of enities
makes it a huge increase in total amount of possibilities. This gives me the
feeling that using the evaluation class wastes a lot of time evaluation
solution which would never be viable.
Since the original post is 1 and a half years old and a lot of new versions
have been released since then, I was wondering if the same solution applies
to my problem aswell and how it compares to my solution which i described
below.
At the moment i solved it as follows:
PlanningEntity A has the following @PlanningVariable annotation
a class x where the @ValueRangeProvider of x is provided by the
@PlanningSolution annotated class.
a class y where the @ValueRangeProvider uses x to provide the subset of
classes y if x is not null, otherwise it returns an empty list<Y> (code
below)
@ValueRangeProvider(id = "timePeriods")
public List<Period> getTimePeriods(){
ScheduleBlock s = getScheduleBlock();
if(s == null) {
return new ArrayList<Period>();
}
return getScheduleBlock().getTimePeriods();
}
This feels like a hack/workaround for the problem but feel free to let me
know what you think,
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).
If it does work for you, I am interested to know more about this - so I
can consider to make this approach legal.
Thanks
--
View this message in context:
http://drools.46999.n3.nabble.com/rules-users-Drools-Planner-what-if-poss...
Sent from the Drools: User forum mailing list archive at Nabble.com.
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
2:38 p.m.
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?
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.pn...
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.
If have any more questions feel free to ask, we are all working to make
OptaPlanner better. I can even send you a zip of my current code if you are
interested.
--
View this message in context:
http://drools.46999.n3.nabble.com/rules-users-Drools-Planner-what-if-poss...
Sent from the Drools: User forum mailing list archive at Nabble.com.
3 p.m.
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.pn...
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-poss...
Sent from the Drools: User forum mailing list archive at Nabble.com.
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
11:20 a.m.
ge0ffrey wrote
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.
Ah yes I see, misread it.
ge0ffrey wrote
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!
I thought of option B myself aswell, a valid solution (since multiple
Observations should be using the same block) but couldnt get it working.
From what I understand it should be used like this:
@ValueRange(type = ValueRangeType.FROM_PLANNING_ENTITY_PROPERTY)
But the only time I have seen the above used was in a version 5.5 or lower
(I'm using 6.0.1.Final) and my optaplanner-core dependency can't find
@ValueRange annotation.
I however did notice use of something similiar in the 6.0.1 documentation
(http://docs.jboss.org/drools/release/6.0.1.Final/optaplanner-docs/html_si...)
look for "4.3.5.2.2. ValueRangeProvider on a planning entity". But can't
seem to find the code for this in the 6.0.1.Final code example.
So basically my question comes down to how do i use "ValueRange from
planning entity" I tried searching for it but couldn't find it anywehere
except on version 5.5 or below as describer above.
--
View this message in context:
http://drools.46999.n3.nabble.com/rules-users-Drools-Planner-what-if-poss...
Sent from the Drools: User forum mailing list archive at Nabble.com.
11:39 a.m.
ignore post above misread your statement about option B
Option B will not work if a block contains multiple observations as you
stated, which is the case in my problem.
--
View this message in context:
http://drools.46999.n3.nabble.com/rules-users-Drools-Planner-what-if-poss...
Sent from the Drools: User forum mailing list archive at Nabble.com.
3640
days inactive
4154
days old
8 comments
3 participants
participants (3)
-
dBijkoo -
Geoffrey De Smet -
Willem van Asperen