[jboss-jira] [JBoss JIRA] (JBRULES-3555) Allow to specify a relative value for the entity tabu
[
https://issues.jboss.org/browse/JBRULES-3555?page=com.atlassian.jira.plug...
]
Geoffrey De Smet commented on JBRULES-3555:
-------------------------------------------
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 itin
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