[jboss-jira] [JBoss JIRA] (JBRULES-3555) Allow to specify a relative value for the entity tabu

[Geoffrey De Smet (JIRA)]

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

Geoffrey De Smet edited comment on JBRULES-3555 at 6/24/12 3:10 AM:
--------------------------------------------------------------------

Instead of $totalNumberOfEntities, it's also possible to use SolutionDescription.getProblemScale(), but I agree for entityTabu, the entitySize makes most sense. Similar for valueTabu, use the valueRangeSize. If there are multiple entity classes, its the sum of the entitySizes. If there are multiple variables on the same entity, it's the minimal valueRangeSize. If there are multiple variables on different entities, it's the sum of the minimal valueRangeSize per entity. SolutionDescription (and indirectly EntityDescription) should implement the calculations as descriped above.

Since the tabu size in the description above is still static during a single solver run, any tabuSize adjustments should be happen in AcceptorConfig, not in a subclass of Acceptor.
Note: First make sure that LocalSearchSolverPhaseConfig#buildDecider() passes the solutionDescriptor to AcceptorConfig#buildAcceptor().


The idea's of negative number and percentage might be a good idea, but I doubt that both of them are useful. We need experimentation to prove that, for example, "percentage" isn't *always* better then "negative number" (or vica versa). So my suggestion is to implement both in AcceptorConfig, run benchmarks with both and delete one. Keeping a consistently inferior one around is confusing for the user.
Percentage must be 0.0 <= percentage <= 1.0. I 'd also name it "...Ratio" (better name welcome).
I 'd define "negative number" as the positive number "nonTabuSize" or "untabuSize" (better name welcome), signaling it's the number of entities which are not tabu.
Maybe "inclusive/exclusive" (think ANT) can be used in naming too.



PS: We need experimentation with dynamic tabu sizes that adjust themselves at runtime too (in a subclass of Acceptor). The results of such experimentation might impact the design/need of this feature... but I don't think we're willing to wait for that? (so just ignore this PS :)


Workaround outside Planner: overwrite every tabuSize in the benchmarkconfig. Or hack it in your *BenchmarkerApp to adjust the tabuSize with java *Config api based on the loaded dataset's size.

                
      was (Author: ge0ffrey):
    Instead of $totalNumberOfEntities, it's also possible to use SolutionDescription.getProblemScale(), but I agree for entityTabu, the entitySize makes most sense. Similar for valueTabu, use the valueRangeSize. If there are multiple entity classes, its the sum of the entitySizes. If there are multiple variables on the same entity, it's the minimal valueRangeSize. If there are multiple variables on different entities, it's the sum of the minimal valueRangeSize per entity. SolutionDescription (and indirectly EntityDescription) should implement the calculations as descriped above.

Since the tabu size in the description above is still static during a single solver run, any tabuSize adjustments should be happen in AcceptorConfig, not in a subclass of Acceptor.
Note: First make sure that LocalSearchSolverPhaseConfig#buildDecider() passes the solutionDescriptor to AcceptorConfig#buildAcceptor().


The idea's of negative number and percentage might be a good idea, but I doubt that both of them are useful. We need experimentation to prove that, for example, "percentage" isn't *always* better then "negative number" (or vica versa). So my suggestion is to implement both in AcceptorConfig, run benchmarks with both and delete one. Keeping a consistently inferior one around is confusing for the user.
Percentage must be 0.0 <= percentage <= 1.0. I 'd also name it "...Ratio" (better name welcome).
I 'd define "negative number" as the positive number "nonTabuSize" or "untabuSize" (better name welcome), signaling it's the number of entities which are not tabu. Maybe "inclusive/exclusive" can be used naming too.



PS: We need experimentation with dynamic tabu sizes that adjust themselves at runtime too (in a subclass of Acceptor). The results of such experimentation might impact the design/need of this feature... but I don't think we're willing to wait for that? (so just ignore this PS :)


Workaround outside Planner: overwrite every tabuSize in the benchmarkconfig. Or hack it in your *BenchmarkerApp to adjust the tabuSize with java *Config api based on the loaded dataset's size.

                  
> Allow to specify a relative value for the entity tabu
> -----------------------------------------------------
>
>                 Key: JBRULES-3555
>                 URL: https://issues.jboss.org/browse/JBRULES-3555
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-planner
>    Affects Versions: 5.5.0.Beta1
>            Reporter: Lukáš Petrovický
>            Assignee: Geoffrey De Smet
>
> Problems such as the RAS2012 challenge require us to provide a solution for problems of varying size - the number of entities in the various cases ranges from 3 to 30.
> In this case, it is nearly impossible to benchmark all those problems at once using the planning entity tabu. When you specify a tabu size larger than the number of entities, no solutions are accepted and thus the benchmark is useless.
> What I propose is to implement a planning entity tabu size that accepts the two different values:
> - Negative number. That would mean that the tabu would be ($size = $totalNumberOfEntities - $specifiedNumber).
> - Percentage. That would mean that the tabu would be ($size = Math.round($percentage * $totalNumberOfEntities)).
> In both cases, 0 < $size < $totalNumberOfEntities. This way, the planning entity tabu size will become universally usable.

--
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