However it won't solve last Friday's telegraph. I managed to solve
Thursday's by hand, using a series of set conversions intersection and
union (after I'd spent about half an hour on it,) but then I couldn't
remember what I did to put the rule in to the code.

Also Friday's was excellent, I managed to invent a rule using
exclusions to solve it, but it required a lot of paper and about two
hours, in a semi-intelligent brute force way. Unfortunately the rule
doesn't translate well to SQL. I'm so happy, because my father in law
couldn't solve it, and he's a seriously bright bloke.

As for an array based system, they work quite well, because the further
down the array you go, the more hits you get to prove a failure,
because the rows and boxes counter possibilities.

I still have several simple rules to add, such as "when there are two
boxes in a row with the same two digits as their only possibilities,
then there can be no other entries in the row with those digits" etc,
and quite a few simple but deep logical exclusions.

I ultimately believe that the majority of these can be constructed to
force some kind of brute force solution, (it's just a guess of course,)
but I can envisage cases where, 20 odd numbers remaining, there are
multiple possibilities where you don't know you've failed until you're
on the last two digits.



--- UseNet To RIME Gateway {at} 3/7/05 4:05:26 PM ---