Hi Geoffrey,
Before, I was simply using a string id, based upon row and column.
Now I've implemented a simple generator for an integer based id. This
has helped my scoring, as the same two tokens are only matched once,
in order, as opposed to being matched twice (or even three times).
This makes my scores much easier to understand, and was a great help
with debugging my constraints. Speed seems to have gone up some, as
the tree doesn't have to double or triple match tokens in
workingmemory, but I can't vouch for this as only now are my puzzles
being solved properly.
I see your point with regards to the startingSolutionInitializer --
I've moved on today to building some simple configurators for the
problems I wish to check based on XML (using Jdom). Thanks for all of
your input and help through this process; I'm immensely pleased with
the end result and will work to pass on feedback as I continue to use
the tool.
best wishes,
Andrew
---------------------------------
Andrew Waterman
San Cristóbal de las Casas, Chiapas, Mexico
+52 1 967 107 5902
+1 510 342 5693
On Feb 18, 2009, at 1:48 PM, Geoffrey De Smet wrote:
With kind regards,
Geoffrey De Smet
Andrew Waterman schreef:
Hi,
Thanks for the rules suggestions, using a simple generated id has
radically improved my solver times (and my scoring).
It surprises me that generated id's radically improve solver times.
Could you give an example of what you changed?
relativeSelection should radically improve solver times, if tweaked
correctly.
I'm now looking
into using the StartingSolutionInitializer code to feed
startingSolutions into the solver.
I'm a little confused about the intended functionality in the
interface, and wanted to get some feedback. Basically, the simple
solver that we had used previously to find our solution space,
didn't take into account any of the topographical constraints of
our game board. The solutions it offered are not highly specific,
in the sense that one doesn't know where all the tokens should be
placed. What it does offer are distributions of tokens on the game
board. For example:
4 tokens of managed forest per territory.
4 tokens of moderate pasture per territory.
4 tokens of intensive pasture per territory.
I'd like to use the startingSolutionInitializer to take a suggested
distribution, populate our board with those values, and then pass
it back to the solver to solve.
For that you don't really need a startingSolutionInitializer, you
could just set that solution directly as the starting solution on
the solver.
A startSolutionInitializer has the advantage that it can reuse the
instance of the working memory with the score rules to initialize
the starting solution.
Is the initializer the right place to do this? Or should I simply
view the initializer as a deterministic entry point for ordering
and composing an incomplete solution before passing it off to the
solver?
best wishes,
Andrew
---------------------------------
Andrew Waterman
San Cristóbal de las Casas, Chiapas, Mexico
+52 1 967 107 5902
+1 510 342 5693
On Feb 13, 2009, at 8:50 AM, Geoffrey De Smet wrote:
With kind regards,
Geoffrey De Smet
Andrew Waterman schreef:
Hi,
I've been looking through my solver logs and on a problem i have
posed, the solver seems to first initialize and setup a best score:
INFO: Initialization time spend (3) for score (-5000004.0).
Updating best solution and best score.
However, this score is not correct. I use collect to load Tokens
of a certain type for my game, and those that are found, penalize
the system with a constraint:
rule "Too much unclaimed territory"
when
$list : ArrayList ( size > 2) from collect (
Token ($type : type == TokenType.UNDEVELOPED))
then
for (int i = 0; i < $list.size(); i++) {
insertLogical (new IntConstraintOccurrence (
"Too much unclaimed territory",
ConstraintType.NEGATIVE_SOFT, 3, $list));
Doesn't this insert the same logical fact in a loop? So only 1
instance actually remains in the working memory?
If you want to have to list.size() affect the score, just do:
3 * list.size()
}
end
Why use collect anyway?
when
$t1 : Token ($type : type == TokenType.UNDEVELOPED, id1 : id)
$t2 : Token ($type : type == TokenType.UNDEVELOPED, id >
id1, id2 : id)
$t3 : Token ($type : type == TokenType.UNDEVELOPED, id >
id2, id3 : id)
// maybe you need things like this: not Token ($type : type ==
TokenType.UNDEVELOPED, id > id3)
then
insertLogical (new IntConstraintOccurrence ("Too much unclaimed
territory", ConstraintType.NEGATIVE_SOFT, 3, $t1, $t2, $t3));
However, the initial score does not seem to account for these
inserted facts. Due to this, all improving solutions are
rejected, and I see no change in the solution the solver finds
and my starting solution. Any suggestions on how to delay
initialization? Or get the starting score to take into account
this constraint (I've made it SOFT so the values aren't so hard
to follow in the logs, it was initially a HARD constraint). I'd
love to find a way around this problem, I've spent most of the
day playing with different configurations (acceptors and
foragers) trying to find a configuration that works for this base
problem.
best wishes,
Andrew
---------------------------------
Andrew Waterman
San Cristóbal de las Casas, Chiapas, Mexico
+52 1 967 107 5902
+1 510 342 5693
------------------------------------------------------------------------
_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
