[jboss-jira] [JBoss JIRA] Commented: (JBRULES-1232) [solver] Selector refactor: configurable subset selections, topList usage etc

[Geoffrey De Smet (JIRA)]

    [ https://issues.jboss.org/browse/JBRULES-1232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12603371#comment-12603371 ] 

Geoffrey De Smet commented on JBRULES-1232:
-------------------------------------------

this issue is partially out of date: topList is implemented (but doesn't really make much of a difference)

and the way to configure the number of moves that are evaluated is refactored: it only includes winning moves.

> [solver] Selector refactor: configurable subset selections, topList usage etc
> -----------------------------------------------------------------------------
>
>                 Key: JBRULES-1232
>                 URL: https://issues.jboss.org/browse/JBRULES-1232
>             Project: Drools
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: drools-planner
>            Reporter: Geoffrey De Smet
>            Assignee: Geoffrey De Smet
>
> Currently all moves are evaluated at every step (with a MaxAllForager at least) if you use the basic cached move factory selector.
> This doesn't scale well, especially for big data problems where in the beginning, just about every moves improves.
> The neighbourhood size (= amount of selected moves) could for example increase block-wise or timeGradient-wise until an improving solution is found.
> Notice the difference with the usage of FirstImprovingForager.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira