|
| View previous topic :: View next topic |
| Author |
Message |
| xyzzy
| | Joined: 24 Aug 2005 | | Posts: 80 | | : | |
Items |
|
 Posted: Wed Nov 30, 2005 4:55 pm Post subject: |
 |
|
| gsf wrote: |
the input puzzles are simple enough for just F constraints (only candidate value in cell) to handle
|
For all the contests? That explains a lot. If a puzzle isn't solved after finding all singles, it can be declared ambiguous without searching for two solutions. |
|
| Back to top |
|
 |
| gsf
| | Joined: 18 Aug 2005 | | Posts: 411 | | : | | Location: NJ USA |
Items |
|
| Posted: Wed Nov 30, 2005 5:49 pm Post subject: |
|
|
| xyzzy wrote: | | gsf wrote: |
the input puzzles are simple enough for just F constraints (only candidate value in cell) to handle
|
For all the contests? That explains a lot. If a puzzle isn't solved after finding all singles, it can be declared ambiguous without searching for two solutions. |
>1 week ago and I forget details
my contest solver could compile with F or FN constraints
(N: only candidate in row/col/box)
the solver backtracks when the constraints fail to progress
by saying "F constraints handled the input" I meant
"a backtrack search with just F constraint propagation worked best"
meaning that adding any other constraints was overkill,
but backtracking was still (presumably) required
looking back at the entry source the ENUMERATE contest input ran best
with FN constraints, so:
| Code: |
GENERATE:10893 F constraints
SOLVE:10957 F constraints
ENUMERATE:3285 FN constraints
|
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
Igloo Theme Version 1.0 :: Created By: Andrew Charron |
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in
Log in to check your private messages
