[rules-users] [planner] The presumed score is corrupted

Guilherme Kunigami kunigami.dev at gmail.com
Mon Oct 17 11:45:39 EDT 2011


2011/10/14 Geoffrey De Smet <ge0ffrey.spam at gmail.com>

> **
> In your doMove you're doing:
>
> crew.addActivity(activity);
> remainingActivities.remove(activity);
>
> If crew and/or remainingActivities are used by your score rules, the
> working memory should be notified of their changes.
> That's causing the corruption
>
>
Hmm, actually the only object that are being used by the score rules is an
activity. Here's the corresponding .drl:

rule "remainingActivitiesCount"
 when
    $remainingCount : Number() from accumulate(
          $activity : ActivityBundle(),
            sum(1)
        )
    then
        insertLogical(new
IntConstraintOccurrence("remainingActivitiesCount",
                ConstraintType.NEGATIVE_HARD,
                $remainingCount.intValue(),
                null));
end



> Extra advice:
> I think you're making your moves too complex and your domain model too
> complex.
> If you upgrade to 5.3, it will be hard to identify the planning entities.
> There will be many (and I doubt you need more than 1).
> Read
>
> http://docs.jboss.org/drools/release/5.3.0.CR1/drools-planner-docs/html_single/index.html#d0e1411
> and specificly this note in that chapter:
>
> *Do not create unnecessary planning entity classes.* This leads to
> difficult Move implementations and slower score calculation.
>
> For example, do not create a planning entity class to hold the total free
> time of a teacher, which needs to be kept up to date as the Lectureplanning entities change. Instead, calculate the free time in the score
> constraints and put the result per teacher into a logically inserted score
> object.
>
> If historic data needs to be considered too, then create problem fact to
> hold the historic data up to, but *not including*, the planning window (so
> it doesn't change when a planning entity changes) and let the score
> constraints take it into account.
>
>
Thanks for the advice. I'll rethink my model and try to use a single
planning entity.


>
>
>
> Op 14-10-11 15:48, Guilherme Kunigami schreef:
>
>
>
> 2011/10/14 Geoffrey De Smet <ge0ffrey.spam at gmail.com>
>
>>  Probably you forgot to notify the workingMemory.update in the doMove
>> method:
>>
>>     public void doMove(WorkingMemory workingMemory) {
>>         FactHandle factHandle = workingMemory.getFactHandle(activity);
>>         activity.setAssignee(...);
>>         workingMemory.update(factHandle, activity);
>>     }
>>
>> Op 14-10-11 09:21, Geoffrey De Smet schreef:
>>
>> A corrupted score normally indicates a problem with the Move
>> implementation (or sometimes the score drl).
>>
>> Basically this happened: for a number of moves, it did the move,
>> calculated the score and undo the move.
>> One of those move was associated with a score -10hard/0soft, that was the
>> best one.
>> Now, it does that move (which is now called the "step") and when it
>> calculates the score it's a different score 0hard/0soft.
>>
>> Try TRACE environment and see if it crashes sooner. Copy paste your Move
>> implementation here.
>>
>>
>  Using the TRACE environment gave the same results of DEBUG.
>
>  Here's my move implementation, as well as the snipet of drools rule file
> that calculates the score based on remaining activities:
>
> http://pastebin.mozilla.org/1355014
>
>
>>   In Planner 5.4 there will be 2 out-of-the-box Move implementations to
>> use, so writing Move's become optional.
>>
>>   Cool!
>
>  By the way, I'm using Drools 5.2.0 final.
>
>  Thanks,
>
>>
>> Op 13-10-11 16:37, Guilherme Kunigami schreef:
>>
>> Hi,
>>
>>  I've implemented a very simple application using drools planner
>> consisting of a bunch of activities. My rule file is very simple too and
>> just counts the number of activities not assigned. When I run
>> Solver.solve(), I get the following error message:
>>
>>  Exception in thread "AWT-EventQueue-0" java.lang.IllegalStateException:
>> The presumedScore (-10hard/0soft) is corrupted because it is not the
>> realScore  (0hard/0soft).
>>
>>  Presumed workingMemory:
>>   Score rule (remainingActivitiesCount) has count (1) and weight total
>> (11).
>> Real workingMemory:
>>   Score rule (remainingActivitiesCount) has count (1) and weight total
>> (0).
>>
>>  I've tracked down this message and found this piece of code
>> @DefaultLocalSearchSolver.solveImplementation():
>>
>>   // there is no need to recalculate the score, but we still need to set
>> it
>>
>> localSearchSolverScope.getWorkingSolution().setScore(localSearchStepScope.getScore());
>> if (assertStepScoreIsUncorrupted) {
>>
>> localSearchSolverScope.assertWorkingScore(localSearchStepScope.getScore());
>> }
>>
>>  It seems that the working score is never updated along the algorithm,
>> but the score in the working memory changes. Thus, when we use the DEBUG
>> environment, assertStepScoreIsUncorrupted is turned on and the assertion
>> fails.
>>
>>  Should the score be updated or am I using the library incorrectly?
>>
>>  Thanks,
>>
>>
>> _______________________________________________
>> rules-users mailing listrules-users at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-users
>>
>>
>> --
>> With kind regards,
>> Geoffrey De Smet
>>
>>
>> _______________________________________________
>> rules-users mailing listrules-users at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-users
>>
>>
>> --
>> With kind regards,
>> Geoffrey De Smet
>>
>>
>> _______________________________________________
>> rules-users mailing list
>> rules-users at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-users
>>
>>
>
> _______________________________________________
> rules-users mailing listrules-users at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-users
>
>
> --
> With kind regards,
> Geoffrey De Smet
>
>
> _______________________________________________
> 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/20111017/3cc2e3bf/attachment.html 


More information about the rules-users mailing list