12:38 a.m.
With reference to issue https://issues.jboss.org/browse/JBRULES-2867 and
thread "Bug in Sudoku Example - with fix"
http://drools-java-rules-engine.46999.n3.nabble.com/Bug-in-Sudoku-Example...,
sudoku example in Drools 5.1 is not working correctly.
drools version: 5.1.1
Although the fix in "Bug in Sudoku Example - with fix" (not
(PossibleCellValue( row == $row, value == $value ) || ResolvedCellValue( row
== $row, value == $value) ) ) can fix the problem, I don't understand why
rule #6, rule #7 and rule #8 are fired before rule #3, rule #4 and rule #5
even through rules #3, #4 and #5 have higher salience. If rules #3, #4 and
#5 have been fired first as expected, then PossibleCellValue with same value
as ResolvedCellValue should have been retracted (so there is no need to
check against ResolvedCellValue in rules #6, #7 and #8)
Does it mean that salience will not be always followed strictly during
runtime? Or it is an issue to be fixed in 5.2?
I understand that dependence on salience is discouraged, however without it,
extra condition is required.
--
View this message in context:
http://drools-java-rules-engine.46999.n3.nabble.com/Sudoku-example-doesn-...
Sent from the Drools - User mailing list archive at Nabble.com.
1:35 a.m.
i'd like to see sudoku redone, the example we have at the moment is
terrible. in that it uses a different salience per rule to drive it,
which is very bad practice.
Any takers for a more robust sudoku example, that demonstrates best
practice?
Mark
On 19/01/2011 06:38, cafebabe wrote:
With reference to issue https://issues.jboss.org/browse/JBRULES-2867
and
thread "Bug in Sudoku Example - with fix"
http://drools-java-rules-engine.46999.n3.nabble.com/Bug-in-Sudoku-Example...,
sudoku example in Drools 5.1 is not working correctly.
drools version: 5.1.1
Although the fix in "Bug in Sudoku Example - with fix" (not
(PossibleCellValue( row == $row, value == $value ) || ResolvedCellValue( row
== $row, value == $value) ) ) can fix the problem, I don't understand why
rule #6, rule #7 and rule #8 are fired before rule #3, rule #4 and rule #5
even through rules #3, #4 and #5 have higher salience. If rules #3, #4 and
#5 have been fired first as expected, then PossibleCellValue with same value
as ResolvedCellValue should have been retracted (so there is no need to
check against ResolvedCellValue in rules #6, #7 and #8)
Does it mean that salience will not be always followed strictly during
runtime? Or it is an issue to be fixed in 5.2?
I understand that dependence on salience is discouraged, however without it,
extra condition is required.
3:03 a.m.
Hi,
On Wed, Jan 19, 2011 at 8:35 AM, Mark Proctor <mproctor(a)codehaus.org> wrote:
Any takers for a more robust sudoku example, that demonstrates best
practice?
I'm considering volunteering as a learning exercise. Won't be perfect
at first, but you can drill me on those best practices for free :-)
However I don't understand how backtracking is done for speculative
facts inserted by rule #11.
Also I only see the need for 4 distinct salience levels: housekeeping,
single elimination, double elimination, branching.
Using "aggregate count" I could get rid of ResolvedCellValue
altogether, then salience becomes an optimization, not a part of the
logic influencing the outcome.
Is there such a thing as "removeLogical", or should we invert the
whole logic (accumulate EliminatedCellValues instead of removing
Possibles) to make use of insertLogical for a more interactive
experience?
BTW Sudoku is such a textbook case for Constraint Logic Programming,
the example documentation could mention the possibility of using
something other than Drools if the domain problem resembles this one
too much :-)
Gabor
5089
days inactive
5089
days old
2 comments
3 participants
participants (3)
-
cafebabe -
Gabor Szokoli -
Mark Proctor