2:26 p.m.
Hi,
I am struggling with the purpose of difficultyWeightFactoryClass in the @PlanningEntity
annotation.
I thought it was used to indicate which PlanningEntities to handle first in order to get
faster to a solution.
Though it seems that it also has impact on whether or not to get to a zero-hardscore
solution.
I mean I have a testcase that resolves to a zero-hardscore solution.
Then I change something small in how the difficultyWeightFactoryClass calculates the
weight and all the sudden I get a negative-hardscore solution.
I thought it would still get to the same zero-hardscore solution but in a shorter solving
time.
My solver termination is as follows:
<termination>
<terminationCompositionStyle>OR</terminationCompositionStyle>
<maximumSecondsSpend>3600</maximumSecondsSpend>
<scoreAttained>0hard/0soft</scoreAttained>
</termination>
and constructionHeuristic:
<constructionHeuristic>
<constructionHeuristicType>BEST_FIT_DECREASING</constructionHeuristicType>
</constructionHeuristic>
I do not reach a zero-hardscore and the time spent is about 2.8 seconds...
If I read the best solution I get:
.isEveryProblemFactChangeProcessed(): true
.isTerminateEarly(): false
Any idea why I do not get a zero-hardscore solution anymore when only making a small
change to the difficultyWeightFactoryClass logic?
Thanks
Michiel.
-----------------
http://www.codessentials.com - Your essential software, for free!
Follow us at http://twitter.com/#!/Codessentials
3:04 p.m.
Hello Michiel,
I thought it was used to indicate which PlanningEntities to handle
first in order to get faster to a solution.
To my understanding this is not quite true. DifficultyWeight defines
what Entities will likely be more difficult to plan, period.
What is actually DONE with this statement (of difficulty) is decided by
meta heuristics algorithm and/or by different selectors (not sure about
this one though). What I am saying
- difficulty weight just says "yo, dude, this planning entity is
hard/easy to plan"
- meta heuristics algorithm (also construction heuristics) then say "oh
great, then I start with easy ones" or "oh dude, then I get first down
to hard ones" or even "nice, but I don't give a damn about difficulty
whatdoyaknow"
*assumption mode on*
The reason why you all of the sudden get negative hard score MIGHT be
that the "right" entities are falling out of the selection. And this is
controlled by meta heuristics algorithm.
As I understand all the meta heuristics magic - it can solve problems
with the space of 10^650 because... it cheats! Yes, it does not evaluate
ALL of the possible values (entities or planning variables) but selects
a subset of those (the ones likely to yield a solution).
And one more thought - changing difficulty weight calculation (in
factory) should normaly NOT have such a drastic influence on score (up
to now I used difficulty weight calcs to increase performance). So I am
suggesting here that the issue MAY lay some other place (typical would
be local optima).
*assumption mode off*
In drools planner docs there is some decent information on selection of
stuff. If I may suggest, start with construction heuristic types and
check out the docs where it says what BEST_FIT or, respectively,
BEST_FIT_DECREASING does.
I hope I could at least give you couple of ideas on where to proceed
with the issue.
br
Reinis
On 01/07/2013 09:26 PM, Michiel Vermandel wrote:
Hi,
I am struggling with the purpose of difficultyWeightFactoryClass in
the @PlanningEntity annotation.
I thought it was used to indicate which PlanningEntities to handle
first in order to get faster to a solution.
Though it seems that it also has impact on whether or not to get to a
zero-hardscore solution.
I mean I have a testcase that resolves to a zero-hardscore solution.
Then I change something small in how the difficultyWeightFactoryClass
calculates the weight and all the sudden I get a negative-hardscore
solution.
I thought it would still get to the same zero-hardscore solution but
in a shorter solving time.
My solver termination is as follows:
<termination>
<terminationCompositionStyle>OR</terminationCompositionStyle>
<maximumSecondsSpend>3600</maximumSecondsSpend>
<scoreAttained>0hard/0soft</scoreAttained>
</termination>
and constructionHeuristic:
<constructionHeuristic>
<constructionHeuristicType>BEST_FIT_DECREASING</constructionHeuristicType>
</constructionHeuristic>
I do not reach a zero-hardscore and the time spent is about 2.8 seconds...
If I read the best solution I get:
.isEveryProblemFactChangeProcessed(): true
.isTerminateEarly(): false
Any idea why I do not get a zero-hardscore solution anymore when only
making a small change to the difficultyWeightFactoryClass logic?
Thanks
Michiel.
-----------------
http://www.codessentials.com - Your essential software, for free!
Follow us at http://twitter.com/#!/Codessentials
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
1:32 a.m.
Some extra info, on top of Reinis's excellent advice:
Take a look at this image:
https://hudson.jboss.org/hudson/view/Drools%20jBPM/job/drools-planner/las...
As the image shows, <constructionHeuristics> don't result into an
optimal solution.
You need to do <localSearch> after it too.
Oversimplifiedly speaking, Construction heuristics are fast and brittle,
Local Search is slow and robust.
Only construction heuristics *_FIT_DECREASING use
difficultyWeightFactoryClass.
By giving a better estimation of the planning difficulty of a entity,
the construction heuristics perform better and Local Search has to do
less work for the same result.
Read these sections in the manual:
Without difficultyWeight:
http://docs.jboss.org/drools/release/5.5.0.Final/drools-planner-docs/html...
With difficultyWeight (the result of FFD is statistically better than FF):
http://docs.jboss.org/drools/release/5.5.0.Final/drools-planner-docs/html...
DifficultyWeight details:
http://docs.jboss.org/drools/release/5.5.0.Final/drools-planner-docs/html...
Op 07-01-13 22:04, Reinis schreef:
Hello Michiel,
>I thought it was used to indicate which PlanningEntities to handle
first in order to get faster to a solution.
To my understanding this is not quite true. DifficultyWeight defines
what Entities will likely be more difficult to plan, period.
What is actually DONE with this statement (of difficulty) is decided by
meta heuristics algorithm and/or by different selectors (not sure about
this one though). What I am saying
- difficulty weight just says "yo, dude, this planning entity is
hard/easy to plan"
- meta heuristics algorithm (also construction heuristics) then say "oh
great, then I start with easy ones" or "oh dude, then I get first down
to hard ones" or even "nice, but I don't give a damn about difficulty
whatdoyaknow"
*assumption mode on*
The reason why you all of the sudden get negative hard score MIGHT be
that the "right" entities are falling out of the selection. And this is
controlled by meta heuristics algorithm.
As I understand all the meta heuristics magic - it can solve problems
with the space of 10^650 because... it cheats! Yes, it does not evaluate
ALL of the possible values (entities or planning variables) but selects
a subset of those (the ones likely to yield a solution).
And one more thought - changing difficulty weight calculation (in
factory) should normaly NOT have such a drastic influence on score (up
to now I used difficulty weight calcs to increase performance). So I am
suggesting here that the issue MAY lay some other place (typical would
be local optima).
*assumption mode off*
In drools planner docs there is some decent information on selection of
stuff. If I may suggest, start with construction heuristic types and
check out the docs where it says what BEST_FIT or, respectively,
BEST_FIT_DECREASING does.
I hope I could at least give you couple of ideas on where to proceed
with the issue.
br
Reinis
On 01/07/2013 09:26 PM, Michiel Vermandel wrote:
> Hi,
>
> I am struggling with the purpose of difficultyWeightFactoryClass in
> the @PlanningEntity annotation.
>
> I thought it was used to indicate which PlanningEntities to handle
> first in order to get faster to a solution.
> Though it seems that it also has impact on whether or not to get to a
> zero-hardscore solution.
> I mean I have a testcase that resolves to a zero-hardscore solution.
> Then I change something small in how the difficultyWeightFactoryClass
> calculates the weight and all the sudden I get a negative-hardscore
> solution.
> I thought it would still get to the same zero-hardscore solution but
> in a shorter solving time.
>
> My solver termination is as follows:
>
> <termination>
> <terminationCompositionStyle>OR</terminationCompositionStyle>
> <maximumSecondsSpend>3600</maximumSecondsSpend>
> <scoreAttained>0hard/0soft</scoreAttained>
> </termination>
>
> and constructionHeuristic:
>
> <constructionHeuristic>
>
<constructionHeuristicType>BEST_FIT_DECREASING</constructionHeuristicType>
> </constructionHeuristic>
>
> I do not reach a zero-hardscore and the time spent is about 2.8 seconds...
>
> If I read the best solution I get:
> .isEveryProblemFactChangeProcessed(): true
> .isTerminateEarly(): false
>
> Any idea why I do not get a zero-hardscore solution anymore when only
> making a small change to the difficultyWeightFactoryClass logic?
>
> Thanks
>
> Michiel.
> -----------------
> http://www.codessentials.com - Your essential software, for free!
> Follow us at http://twitter.com/#!/Codessentials
>
>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
3:23 a.m.
Many thanks Geoffrey and Reinis for the advice and directions.
One more question: is it possible that the solver stops in 2.8 seconds with a negative
score solution even the termination config says hardscore 0 OR 3600 seconds?
Or do I have something wrong?
Or is it the local search that will be cut off?
Thanks
Michiel
-----------------
http://www.codessentials.com - Your essential software, for free!
Follow us at http://twitter.com/#!/Codessentials
________________________________
From: Geoffrey De Smet <ge0ffrey.spam(a)gmail.com>
To: Rules Users List <rules-users(a)lists.jboss.org>
Sent: Tuesday, January 8, 2013 8:32 AM
Subject: Re: [rules-users] Purpose of difficultyWeightFactoryClass in @PlanningEntity
annotation.
Some extra info, on top of Reinis's excellent advice:
Take a look at this image:
https://hudson.jboss.org/hudson/view/Drools%20jBPM/job/drools-planner/las...
As the image shows, <constructionHeuristics> don't result into an
optimal solution.
You need to do <localSearch> after it too.
Oversimplifiedly speaking, Construction heuristics are fast and brittle,
Local Search is slow and robust.
Only construction heuristics *_FIT_DECREASING use
difficultyWeightFactoryClass.
By giving a better estimation of the planning difficulty of a entity,
the construction heuristics perform better and Local Search has to do
less work for the same result.
Read these sections in the manual:
Without difficultyWeight:
http://docs.jboss.org/drools/release/5.5.0.Final/drools-planner-docs/html...
With difficultyWeight (the result of FFD is statistically better than FF):
http://docs.jboss.org/drools/release/5.5.0.Final/drools-planner-docs/html...
DifficultyWeight details:
http://docs.jboss.org/drools/release/5.5.0.Final/drools-planner-docs/html...
Op 07-01-13 22:04, Reinis schreef:
Hello Michiel,
>I thought it was used to indicate which PlanningEntities to handle
first in order to get faster to a solution.
To my understanding this is not quite true. DifficultyWeight defines
what Entities will likely be more difficult to plan, period.
What is actually DONE with this statement (of difficulty) is decided by
meta heuristics algorithm and/or by different selectors (not sure about
this one though). What I am saying
- difficulty weight just says "yo, dude, this planning entity is
hard/easy to plan"
- meta heuristics algorithm (also construction heuristics) then say "oh
great, then I start with easy ones" or "oh dude, then I get first down
to hard ones" or even "nice, but I don't give a damn about difficulty
whatdoyaknow"
*assumption mode on*
The reason why you all of the sudden get negative hard score MIGHT be
that the "right" entities are falling out of the selection. And this is
controlled by meta heuristics algorithm.
As I understand all the meta heuristics magic - it can solve problems
with the space of 10^650 because... it cheats! Yes, it does not evaluate
ALL of the possible values (entities or planning variables) but selects
a subset of those (the ones likely to yield a solution).
And one more thought - changing difficulty weight calculation (in
factory) should normaly NOT have such a drastic influence on score (up
to now I used difficulty weight calcs to increase performance). So I am
suggesting here that the issue MAY lay some other place (typical would
be local optima).
*assumption mode off*
In drools planner docs there is some decent information on selection of
stuff. If I may suggest, start with construction heuristic types and
check out the docs where it says what BEST_FIT or, respectively,
BEST_FIT_DECREASING does.
I hope I could at least give you couple of ideas on where to proceed
with the issue.
br
Reinis
On 01/07/2013 09:26 PM, Michiel Vermandel wrote:
> Hi,
>
> I am struggling with the purpose of difficultyWeightFactoryClass in
> the @PlanningEntity annotation.
>
> I thought it was used to indicate which PlanningEntities to handle
> first in order to get faster to a solution.
> Though it seems that it also has impact on whether or not to get to a
> zero-hardscore solution.
> I mean I have a testcase that resolves to a zero-hardscore solution.
> Then I change something small in how the difficultyWeightFactoryClass
> calculates the weight and all the sudden I get a negative-hardscore
> solution.
> I thought it would still get to the same zero-hardscore solution but
> in a shorter solving time.
>
> My solver termination is as follows:
>
> <termination>
> <terminationCompositionStyle>OR</terminationCompositionStyle>
> <maximumSecondsSpend>3600</maximumSecondsSpend>
> <scoreAttained>0hard/0soft</scoreAttained>
> </termination>
>
> and constructionHeuristic:
>
> <constructionHeuristic>
>
<constructionHeuristicType>BEST_FIT_DECREASING</constructionHeuristicType>
> </constructionHeuristic>
>
> I do not reach a zero-hardscore and the time spent is about 2.8 seconds...
>
> If I read the best solution I get:
> .isEveryProblemFactChangeProcessed(): true
> .isTerminateEarly(): false
>
> Any idea why I do not get a zero-hardscore solution anymore when only
> making a small change to the difficultyWeightFactoryClass logic?
>
> Thanks
>
> Michiel.
> -----------------
> http://www.codessentials.com - Your essential software, for free!
> Follow us at http://twitter.com/#!/Codessentials
>
>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
4:55 a.m.
Unless you don't have a <localSearch> configuration of
course.
Indeed, somewhere during my testing and trying to figure out what the use of
each configuration part is, I stripped out the local search part.
Never noticed it because I always got zero score so far...
Ok, on to localSearch.
Thanks!
-----------------
http://www.codessentials.com - Your essential software, for free!
Follow us at http://twitter.com/#!/Codessentials
________________________________
From: Geoffrey De Smet <ge0ffrey.spam(a)gmail.com
Op 08-01-13 10:23, Michiel Vermandel schreef:
Many thanks Geoffrey and Reinis for the advice and directions.
>One more question: is it possible that the solver stops in
2.8
seconds with a negative score solution even the termination
config says hardscore 0 OR 3600 seconds?
>
No, presuming that that's a negative hardscore.
Does Solver.solve() throw an exception?
If not, what does the logging say? If that doesn't say anything,
enable
INFO or DEBUG logging (see manual).
>
>>Thanks
>
>>Michiel
>
>
>
>>
>>-----------------
>>http://www.codessentials.com
- Your essential software, for free!
>>Follow us at http://twitter.com/#%21/Codessentials
>
>
>>________________________________
>> From: Geoffrey De Smet <ge0ffrey.spam(a)gmail.com>optimal solution.
>You need to do <localSearch> after it too.
>Oversimplifiedly speaking, Construction heuristics are
fast and
brittle,
>>Local Search is slow and robust.
>
>>Only construction heuristics *_FIT_DECREASING use
>>difficultyWeightFactoryClass.
>>By giving a better estimation of the planning difficulty
of a entity,
>the construction heuristics perform better and Local
Search has to do
>>less work for the same result.
>
>>Read these sections in the manual:
>>Without difficultyWeight:
>>http://docs.jboss.org/drools/release/5.5.0.Final/drools-planner-docs/html_single/index.html#d0e6076
>>With difficultyWeight (the result of FFD is statistically
better than FF):
>>http://docs.jboss.org/drools/release/5.5.0.Final/drools-planner-docs/html_single/index.html#d0e6126
>>DifficultyWeight details:
>>http://docs.jboss.org/drools/release/5.5.0.Final/drools-planner-docs/html_single/index.html#planningEntityDifficulty
>
>>Op 07-01-13 22:04, Reinis schreef:
>>> Hello Michiel,
>>
>>> >I thought it was used to indicate which
PlanningEntities to handle
>>> first in order to get faster to a solution.
>>
>>> To my understanding this is not quite true.
DifficultyWeight defines
>> what Entities will likely be more difficult to plan,
period.
>>
>>> What is actually DONE with this statement (of
difficulty) is decided by
>> meta heuristics algorithm and/or by different
selectors (not sure about
>> this one though). What I am saying
>> - difficulty weight just says "yo, dude, this
planning
entity is
>> hard/easy to plan"
>> - meta heuristics algorithm (also construction
heuristics)
then say "oh
>> great, then I start with easy ones" or "oh dude,
then
I get first down
>> to hard ones" or even "nice, but I don't give a
damn
about difficulty
>>> whatdoyaknow"
>>
>>> *assumption mode on*
>>> The reason why you all of the sudden get negative
hard score MIGHT be
>> that the "right" entities are falling out of the
selection. And this is
>>> controlled by meta heuristics algorithm.
>>
>>> As I understand all the meta heuristics magic
- it
can solve problems
>> with the space of 10^650 because... it cheats! Yes,
it does not evaluate
>> ALL of the possible values (entities or planning
variables) but selects
>> a subset of those (the ones likely to yield a
solution).
>>
>>> And one more thought - changing difficulty
weight
calculation (in
>> factory) should normaly NOT have such a drastic
influence on score (up
>> to now I used difficulty weight calcs to increase
performance). So I am
>> suggesting here that the issue MAY lay some other
place (typical would
>>> be local optima).
>>> *assumption mode off*
>>
>>> In drools planner docs there is some decent
information on selection of
>> stuff. If I may suggest, start with construction
heuristic types and
>> check out the docs where it says what BEST_FIT or,
respectively,
>>> BEST_FIT_DECREASING does.
>>
>>> I hope I could at least give you couple of
ideas on
where to proceed
>>> with the issue.
>>
>>> br
>>> Reinis
>>
>>> On 01/07/2013 09:26 PM, Michiel Vermandel
wrote:
>>>> Hi,
>>>
>>>> I am struggling
with the purpose of
difficultyWeightFactoryClass in
>>>> the @PlanningEntity annotation.
>>>
>>>> I thought it
was used to indicate which
PlanningEntities to handle
>>> first in order to get faster to a solution.
>>> Though it seems that it also has impact on
whether or not
to get to a
>>> zero-hardscore solution.
>>> I mean I have a testcase that resolves to a
zero-hardscore solution.
>>> Then I change something small in how the
difficultyWeightFactoryClass
>>> calculates the weight and all the sudden I get a
negative-hardscore
>>> solution.
>>> I thought it would still get to the same
zero-hardscore
solution but
>>>> in a shorter solving time.
>>>
>>>> My solver
termination is as follows:
>>>
>>>>
<termination>
<terminationCompositionStyle>OR</terminationCompositionStyle>
<maximumSecondsSpend>3600</maximumSecondsSpend>
<scoreAttained>0hard/0soft</scoreAttained>
>>>> and
constructionHeuristic:
>>>
>>>>
<constructionHeuristic>
<constructionHeuristicType>BEST_FIT_DECREASING</constructionHeuristicType>
>>>> I do not reach a zero-hardscore and the time
spent is about 2.8 seconds...
>>>
>>>> If I read the
best solution I get:
>>>> .isEveryProblemFactChangeProcessed(): true
>>>> .isTerminateEarly(): false
>>>
>>>> Any idea why I
do not get a zero-hardscore
solution anymore when only
>>> making a small change to the
difficultyWeightFactoryClass logic?
>>>
>>>> Thanks
>>>
>>>> Michiel.
>>>> -----------------
>>>> http://www.codessentials.com - Your essential software, for free!
>>>> Follow us at http://twitter.com/#!/Codessentials
>>>
>>>
>>>>
_______________________________________________
>>>> rules-users mailing list
>>>> rules-users(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/rules-users
>>> _______________________________________________
>>> rules-users mailing list
>>> rules-users(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/rules-users
>>
>
>>_______________________________________________
>>rules-users mailing list
>>rules-users(a)lists.jboss.org
>>https://lists.jboss.org/mailman/listinfo/rules-users
>
>
>
>
>
>>_______________________________________________
rules-users mailing list rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
4337
days inactive
4338
days old
6 comments
3 participants
participants (3)
-
Geoffrey De Smet -
Michiel Vermandel -
Reinis