The generation of ambiguous puzzles is a known bug. None of the authors
has the time to do anything about it at this time.
OK, well, at least that simplifies determining this bug's severity.
However, I would argue that the poster overestimates the seriousness of
it.
1. Nowhere I can find is there some official definition of Su Doku
that states puzzles must be unambiguous, although I acknowlege
that it is conventional.
From http://en.wikipedia.org/wiki/Sudoku : "It is possible to set
starting grids with more than one solution and to set grids with no
solution, but such are not considered proper /Sudoku/ puzzles; as in
most other pure-logic puzzles, a unique solution is expected."
2. gnudoku also serves to load puzzles obtained elsewhere, as well
as solving puzzles the user inputs.
The presence of ksudoku and gnome-sudoku in testing also makes the
transition of gnudoku to testing quite useless
I don't know how debian operates, but I didn't realise that an
application had to satisfy a criterion of usefulness compared to
existing alternatives to be allowed into the distribution.
A new application's usefullness is obviously relative to the existing
applications, but this isn't really the problem here. Before gnudoku
enters testing, the question is more whether gnudoku's usefullness
compensates the frustration this bug would cause to users.
I don't know how to deal with this bug. I am quite surprised of its
severity since I totally agree with John.
Of course I don't want to start a "severity war" so I just mark the bug
with the help tag.
Hi David, I'm happy to see your reply. IMO this bug is important. I
don't know whether it should be serious. This is mostly why I opened
this last week and asked to consider bumping the bug to serious. I was
expecting feedback from you, but this didn't happen until I upgraded the
bug, so I thought you were missing and not aware of the bug. I chose to
upgrade this to serious because I wanted you to judge this bug's
severity before gnudoku enters testing. Now that you're clearly aware of
it, it's your call to downgrade this bug or not. It's theorically your
privilege to make a bug serious, so I won't infringe this once more and
there won't be any severity war. This bug isn't RC according to any
Debian policy, so it's your privilege to set it's severity.
I'll still precise why I think this is serious since I'm the only one
that seems to think that. As John says, generating puzzles is only one
of gnudoku's features. Let's start by analyzing puzzle generation. I
don't know how you play sudoku, but I progress by filling 1 case for
which I deducted the content at a time. If I can't fill a single case, I
try more or abdicate. It's certainly possible to complete puzzles with
multiple solutions, but I'd have to use a different solving method, and
I don't think I'd enjoy. The problem is that if gnudoku generates
puzzles with multiple solutions sometimes, I have to either put the
initial puzzle in a different solver like logicgamesonline.com's, check
whether it has multiple solutions and generate a new puzzle if it does
(then repeat) or try puzzles anyway and always wonder whether the
solving method I use is ineffective or if I should just try harder. The
level of uncertainty caused by this issue depends on the proportion of
puzzles with multiple solutions generated by gnudoku. In my case this
proportion is 1 up to now. I may have that proportion wrong (hopefully
it's actually lower :) ) but I'm already sure that I won't ever enjoy
solving a puzzle generated by current gnudoku again without making sure
it has a unique solution first. And doing that is also painful (and
relies on other software being available anyway). Also, this description
is only valid once the user is aware of the bug. In my case, I said to
Josh Metzler that I was unable to solve the first puzzle generated by
gnudoku only 7 digits away from completion and thought I was getting
dumb, and he replied that the puzzle had multiple solutions. But most
people probably don't know authors of Sudoku websites and are not so
lucky :) Probably that someone would try a first puzzle, abdicate after
a long time, try again, abdicate, lower the difficulty. Then if gnudoku
generates one puzzle with a single solution, people are probably only
going to take more time to realize that the bug isn't in their brain and
look at the BTS.
And then there are the other uses of gnudoku. IMHO gnudoku is reasonably
useful to solve puzzles obtained elsewhere. It's certainly not as good
as ksudoku, but it will at least warn about direct conflicts and be a
bit more useful than paper. gnudoku can also compute solutions. AFAIK it
does that well. gnudoku should also be rather useful to verify solutions.
So gnudoku does at least three things well. However, here it can be
noted that there is already software in Etch that does that. I haven't
tried gnome-sudoku. I know that ksudoku does all three, usually better.
gnudoku does have the merit of doing it without depending on either
libgnome or kdelibs. Now, does this compensate the frustration users
will most likely experience before learning about the bug? IMO, no, but
I would understand the maintainer to disagree about this. I note that
the description reads "A program for creating and solving SuDoku
puzzles", so "creating" comes first. This order may be random, but
solving puzzles created by gnudoku is the first use for me (and only,
until I try using it to debug a fourth sudoku program ;) ).
I think there's still a simple thing that could be done to avoid
frustrating users...just mention the bug in the software. This is of
course ugly, but used sometimes in special cases. I remember gnome-apt
issuing a big warning that it was buggy or something like that at
startup. I never really tried it past this point, but I'm not
frustrated/ashamed that it's in Debian stable.
Aside from that, and this is more for upstream than for an immediate
handling of this bug, John didn't give much details about solving the
issue for good. gnudoku appears to be C++, and ksudoku does the
generation well and has a function to determine if a puzzle has multiple
solutions. Is stealing this code realistic, or would it still be too
much time-expensive? Maybe also make a libsudoku? :-P
Hum, sorry for the long mail :/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
