[jboss-svn-commits] JBL Code SVN: r15368 - labs/jbossrules/trunk/documentation/manual/en/Chapter-Solver.
jboss-svn-commits at lists.jboss.org
jboss-svn-commits at lists.jboss.org
Tue Sep 25 15:49:11 EDT 2007
Author: ge0ffrey
Date: 2007-09-25 15:49:11 -0400 (Tue, 25 Sep 2007)
New Revision: 15368
Modified:
labs/jbossrules/trunk/documentation/manual/en/Chapter-Solver/Section-Local_Search_Solver.xml
labs/jbossrules/trunk/documentation/manual/en/Chapter-Solver/Section-Score_calculation.xml
labs/jbossrules/trunk/documentation/manual/en/Chapter-Solver/Section-Solver_introduction.xml
labs/jbossrules/trunk/documentation/manual/en/Chapter-Solver/nQueensDomainDiagram.dia
labs/jbossrules/trunk/documentation/manual/en/Chapter-Solver/nQueensDomainDiagram.png
Log:
feed-back from Jeroen
Modified: labs/jbossrules/trunk/documentation/manual/en/Chapter-Solver/Section-Local_Search_Solver.xml
===================================================================
--- labs/jbossrules/trunk/documentation/manual/en/Chapter-Solver/Section-Local_Search_Solver.xml 2007-09-25 19:39:15 UTC (rev 15367)
+++ labs/jbossrules/trunk/documentation/manual/en/Chapter-Solver/Section-Local_Search_Solver.xml 2007-09-25 19:49:11 UTC (rev 15368)
@@ -304,7 +304,8 @@
can win performance and scalability. Try it yourself: run both the simple
(small moves) and the smart (big moves) version of the traveling
tournament example. The smart version evaluates a lot less unfeasible
- solutions and exponentially outperformces the simple version.</para>
+ solutions, which enables it to outperform and outscale the simple
+ version.</para>
<para>Move generation currently happens with a
<literal>MoveFactory</literal>:</para>
@@ -418,9 +419,9 @@
<section>
<title>Getting stuck in local optima</title>
- <para>A simple local search always takes improving moves. This may seem
- like a good thing, but it's not. It suffers from a number of
- problems:</para>
+ <para>A <emphasis>simple local search</emphasis> always takes improving
+ moves. This may seem like a good thing, but it's not. It suffers from a
+ number of problems:</para>
<itemizedlist>
<listitem>
@@ -438,9 +439,9 @@
</listitem>
</itemizedlist>
- <para>Luckily drools-solver implements better local searches, such
+ <para>Of course drools-solver implements better local searches, such
<emphasis>tabu search</emphasis> and <emphasis>simulated
- annealing</emphasis> which don't have these problems. It's recommended to
+ annealing</emphasis> which can avoid these problems. It's recommended to
never use a simple local search, unless you're absolutely sure there are
no local optima in your planning problem.</para>
</section>
@@ -541,7 +542,9 @@
<listitem>
<para><emphasis>Solution tabu</emphasis> makes recently visited
solutions tabu. It does not accept a move that leads to one of
- those solutions. We recommend this type of tabu.</para>
+ those solutions. If you can spare the memory, don't be cheap on
+ the tabu size. We recommend this type of tabu because it tends to
+ give the best results and requires little or no tweaking.</para>
<programlisting> <accepter>
<completeSolutionTabuSize>1000</completeSolutionTabuSize>
@@ -601,6 +604,12 @@
<completeUndoMoveTabuSize>10</completeUndoMoveTabuSize>
</accepter></programlisting>
+ <para>If you pick a too small tabu size, your solver can still get
+ stuck in a local optimum. On the other hand, with the exception of
+ solution tabu, if you pick a too large tabu size, your solver can get
+ stuck by bouncing of the walls. Use the benchmarker to fine tweak your
+ configuration.</para>
+
<para>A tabu search accepter should be used with a
<literal>MaxScoreOfAllForager</literal> (recommended) or a
<literal>FirstImprovingScoreForager</literal>.</para>
Modified: labs/jbossrules/trunk/documentation/manual/en/Chapter-Solver/Section-Score_calculation.xml
===================================================================
--- labs/jbossrules/trunk/documentation/manual/en/Chapter-Solver/Section-Score_calculation.xml 2007-09-25 19:39:15 UTC (rev 15367)
+++ labs/jbossrules/trunk/documentation/manual/en/Chapter-Solver/Section-Score_calculation.xml 2007-09-25 19:49:11 UTC (rev 15368)
@@ -171,10 +171,12 @@
scoreCalculator.setScore(- $hardConstraintCount);
end</programlisting>
- <para>You can also weigh your constraints differently, by multiplying the
- count of each score rule with its weight. For example in freight routing,
- you can make 5 broken "avoid crossroads" soft constraints count as much as
- 1 broken "avoid highways at rush hour" soft constraint.</para>
+ <para>Optionally, you can also weigh your constraints differently, by
+ multiplying the count of each score rule with its weight. For example in
+ freight routing, you can make 5 broken "avoid crossroads" soft constraints
+ count as much as 1 broken "avoid highways at rush hour" soft constraint.
+ This allows your business analysts to easily tweak the score function as
+ they see fit.</para>
<para>Here's an example of all the NQueens constraints written as a single
rule, using multi pattern accumulates and making multipleQueensHorizontal
@@ -258,10 +260,10 @@
</listitem>
<listitem>
- <para>If performance is important (and it will be), use at least java
- 1.6 and always use server mode (<literal>java -server</literal>). We
- have seen performance increases of 30% by switching from java 1.5 to
- 1.6 and 50% by turning on server mode.</para>
+ <para>For optimal performance, use at least java 1.6 and always use
+ server mode (<literal>java -server</literal>). We have seen
+ performance increases of 30% by switching from java 1.5 to 1.6 and 50%
+ by turning on server mode.</para>
</listitem>
<listitem>
Modified: labs/jbossrules/trunk/documentation/manual/en/Chapter-Solver/Section-Solver_introduction.xml
===================================================================
--- labs/jbossrules/trunk/documentation/manual/en/Chapter-Solver/Section-Solver_introduction.xml 2007-09-25 19:39:15 UTC (rev 15367)
+++ labs/jbossrules/trunk/documentation/manual/en/Chapter-Solver/Section-Solver_introduction.xml 2007-09-25 19:49:11 UTC (rev 15368)
@@ -76,8 +76,8 @@
scalable</emphasis>.</para>
<para>A planning problem has a number of <emphasis>solutions</emphasis>.
- Each possible solution has a score. We can break down the solutions to a
- planning problem into 3 categories:</para>
+ Each solution has a score. We can break down the solutions of a planning
+ problem into 3 categories:</para>
<itemizedlist>
<listitem>
@@ -144,7 +144,7 @@
$ mvn exec:exec -Dexec.mainClass="org.drools.solver.examples.travelingtournament.app.smart.SmartTravelingTournamentApp"
...</programlisting>
- <para>Here's a screenshot of the NQueens example, which is a simple
+ <para>Here's a screenshot of the n queens example, which is a simple
example:</para>
<mediaobject>
@@ -389,8 +389,8 @@
</itemizedlist>
<para>Brute force is currently not implemented in drools-solver. But we
- have plans to implement in the future, as a reference for validating the
- output of the other solver types.</para>
+ have plans to implement it in the future, as a reference for validating
+ the output of the other solver types.</para>
</section>
<section>
@@ -462,7 +462,7 @@
search path and moves facts around to find a good feasible
solution.</para>
- <para>A vanilla local search can easily get stuck in a local optima, but
+ <para>A simple local search can easily get stuck in a local optima, but
improvements (such as tabu search and simulated annealing) address this
problem.</para>
@@ -490,7 +490,7 @@
<itemizedlist>
<listitem>
- <para>It does not know when it finds an optimal solution.</para>
+ <para>It does not know when it has found an optimal solution.</para>
</listitem>
<listitem>
Modified: labs/jbossrules/trunk/documentation/manual/en/Chapter-Solver/nQueensDomainDiagram.dia
===================================================================
(Binary files differ)
Modified: labs/jbossrules/trunk/documentation/manual/en/Chapter-Solver/nQueensDomainDiagram.png
===================================================================
(Binary files differ)
More information about the jboss-svn-commits
mailing list