[rules-users] Drools planner: The workingMemory has 1 ConstraintOccurrence(s) in excess

[Michiel Vermandel]

Hi,

In order to save time and focus on the bigger (?) problems:

how bad is it to use a sequence number as extra parameter like
insertLogical(new IntConstraintOccurrence("noConsecutiveIV", ConstraintType.NEGATIVE_HARD, ....  Sequence.next() );

to avoid the ConstraintOccurrence(s) in excess (for now) ?

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: Michiel Vermandel <mvermand at yahoo.com>; Rules Users List <rules-users at lists.jboss.org> 
Sent: Tuesday, February 5, 2013 12:19 PM
Subject: Re: Drools planner: The workingMemory has 1 ConstraintOccurrence(s) in excess
 



Op 05-02-13 11:22, Michiel Vermandel schreef:

Hi,
>
>Thanks for the advice.
>
>1) About drools 5.5.1-SNAPSHOT: It doens't seem to be in the
        list of available distros:
> Eclipse > pom > Dependencies > Add > Search
        results.
>After 5.5.0-Final I get the Alphas of 6.0.0.
>I'm not such a wiz in Maven.
>How do I get the 5.5.1-SNAPSHOT into my m2/Nexus repo?
>
Look for "the jboss snapshop repo" on google. See the URL I pasted. Or look in the droolsjbpm-parent pom's <repository> section.


>
>2) I'll do as you advised but here are already the stats:
>I've got 260 planning entities in my test
About the planning variables: I have 3 different types of planning variables but I do not use any default selector. Thus I do not have Entities * Values of possible moves.
>
Normally, one should always also add a changeMoveSelector for every variable (on top of the course grained moves), possibly with a filter to avoid breaking build-in constraints. Try it with the benchmarker.

I reduce quite some moves (I think/hope I do not eliminate the moves that could lead to the optimal solution).
>For the 3 different variable types I have 5 MoveListFactories
        and they produce for the 260 entities all together 8550 possible
        moves.
>
 
>-----------------
>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 at lists.jboss.org 
>Sent: Tuesday, February 5, 2013 9:35 AM
>Subject: Re: [rules-users] Drools planner: The workingMemory has 1 ConstraintOccurrence(s) in excess
> 
>
>
>
>Op 05-02-13 09:16, Michiel Vermandel schreef:
>
>Hi,
>>
>>
>>I am using Drools planner 5.5.0.Final.
>>
>>Once again I have the exception "The workingMemory has 1 ConstraintOccurrence(s) in excess".
>>I have added all relevant planning variables as parameters of the ConstraintOccurrence.
>>
>>Could the following theory be an explanation for
                      this issue? 
>>
>>My dataset is not that big (not small either).
>>Could it be that a certain move is taken twice
                      within the same step (as part of score trap?)
                      which results in the same constraint occurrence?
>>
No, the same move twice in the same step should not cause any trouble.
>If you can prove this causes the score corruption, it's
                a bug in Drools Expert.
>There have been a bunch of bugfixes in drools, so try
                drools (-core, -compiler, knowledge-api, mvel, ...)
                5.5.0-SNAPSHOT:
>   https://repository.jboss.org/nexus/content/groups/public/org/drools/drools-core/5.5.1-SNAPSHOT/drools-core-5.5.1-20130205.051201-93.pom
>If that doesn't help, paste the rule.
>
>
>>I have one other question - maybe related:
>>In my configuration I have this:
>>
>>        <acceptor>
>>         
                      <planningEntityTabuSize>7</planningEntityTabuSize>
                      <!-- I tested with lower values (5, 3) too
                      -->
>>        </acceptor>
>>        <forager>
>>           
                      <pickEarlyType>FIRST_BEST_SCORE_IMPROVING</pickEarlyType>
>>           
                      <minimalAcceptedSelection>1000</minimalAcceptedSelection>
>>        </forager>
>>
>>Because of the forager configuration a step is
                      sometimes taken after as little as 40 moves, but
                      sometimes the number of moves grows to enormous
                      amounts.
>>I think if that happens that the score is no
                      longer improving.
>>Is it "normal" that a certain step can make +50k
                      moves and counting?
>>
you're set at 1k minimalAcceptedSelection, so 50k is a lot indeed.
>This is probably because the planningEntityTabuSize is
                to high compared to the number of entity's in your
                dataset.
>There's a jira for making planningEntityTabuSize
                automatically adjust itself based on the entity size
                (which would solve this).
>Or it could also be because the number of possible moves
                (entity size * value size) is near 1k.
>
>
>Or does indicate once more to a score trap?
>>
No. It indicates that planner's config should scale down automatically.
>How many entity's and values do you have?
>
>
>>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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20130205/6b5ef95c/attachment-0001.html