[rules-users] Purpose of difficultyWeightFactoryClass in @PlanningEntity annotation.

Michiel Vermandel mvermand at yahoo.com
Tue Jan 8 05:55:41 EST 2013


> 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 at gmail.com>
To: Rules Users List <rules-users at lists.jboss.org> 
Sent: Tuesday, January 8, 2013 11:29 AM
Subject: Re: [rules-users] Purpose of difficultyWeightFactoryClass in @PlanningEntity annotation.
 



Op 08-01-13 11:12, Geoffrey De Smet schreef:


>
>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.
>
Unless you don't have a <localSearch> configuration of course.
The <constructionHeuristics> don't run forever: they stop
    fairly fast.
Giving them more time is pointless.
See manual section "Termination" and "SolverPhase".


>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).
>
>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/#%21/Codessentials
>>
>>
>>________________________________
>> From: Geoffrey De Smet <ge0ffrey.spam at gmail.com>
>>To: Rules Users List <rules-users at 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/lastSuccessfulBuild/artifact/drools-planner-docs/target/docbook/publish/en-US/html_single/images/Chapter-Optimization_algorithms/generalPhaseSequence.png
>>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_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>
>>>>      </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 at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/rules-users
>>> _______________________________________________
>>> rules-users mailing list
>>> rules-users at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/rules-users
>>>
>>
>>_______________________________________________
>>rules-users mailing list
>>rules-users at lists.jboss.org
>>https://lists.jboss.org/mailman/listinfo/rules-users
>>
>>
>>
>>
>>
>>_______________________________________________
rules-users mailing list rules-users at lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users 
>
>
>
>_______________________________________________
rules-users mailing list rules-users at lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users 

_______________________________________________
rules-users mailing list
rules-users at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20130108/f4944c48/attachment-0001.html 


More information about the rules-users mailing list