[
https://issues.jboss.org/browse/JBRULES-3471?page=com.atlassian.jira.plug...
]
Geoffrey De Smet commented on JBRULES-3471:
-------------------------------------------
Important note: The last solution is not necessarily the best solution.
Planner reminders the best solution it encounters, but when it hits a local optima, it
will need to do a few steps that have worse solution to get out of it and find a better
local optima.
The log clearly says ", best score", not ", new best score", so
that's normal that that step move isn't in the best solution (unless later a new
best solution is found and no other step move has undone that step move).
Planner 5.4.0CR1: Local Search Phase: Log shows move but best/final
solution does not
-------------------------------------------------------------------------------------
Key: JBRULES-3471
URL:
https://issues.jboss.org/browse/JBRULES-3471
Project: Drools
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: drools-planner
Affects Versions: 5.3.0.Final, 5.4.0.CR1
Environment: Windows XP SP3
java version "1.6.0_31"
Java(TM) SE Runtime Environment (build 1.6.0_31-b05)
Java HotSpot(TM) Client VM (build 20.6-b01, mixed mode, sharing)
Reporter: Vikram Duggal
Assignee: Geoffrey De Smet
While comparing the log file output of the Local Search phase (Tabu) with the final/best
solution, there are several instances where log file shows move occurred but the
final/best solution obtained after time/user termination shows the planning entity still
on previous planning variable.
I saw this issue using 5.3.0 Final and also in 5.4.0CR1.
I saw this issue in my code and also in the "Hospital Bed Planning" examples
bundled in the distribution.
Example (Log output from the Hospital Bed Planning testdata01.xml) -
...
2012-04-20 11:53:35,066 [pool-289-thread-1] DEBUG Step index (27), time spend
(22873), score (0hard/-9292soft), best score (0hard/-9292soft), accepted move size
(500) for picked step ([Patient655(11-11) @ Department4_490_1 => Department1_119_0]).
...
Checking the final solution, I see that Patient655 is still on Department4_490_1
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see:
http://www.atlassian.com/software/jira