Automatický Slitherlink solver

30.8.2010 11:33 | Přečteno: 2123× | GNU | poslední úprava: 30.8.2010 11:43

Přemýšlel jsem jak co nejlépe implementovat řešení tohoto hlavolamu. Použil jsem opět starý dobrý DLX solver, který výborně funguje pro Sudoku, a který docela dobře šel použít i pro Kakuro. Zatím jsem skončil zhruba u tohoto postupu, který dobře (tj do desítek sekund) řeší 7x7 puzzle, a většinu 10x10 puzzlí:

1) Pro střed každého čtverce vygeneruj "tahy", které pokryjí 4 strany tohoto čtverce správným počtem čar. Tj pro "0" bude možnost jen jedna, pro "1" budou 4, pro "2" jich bude 6 apod. Tohle je jednoduché, prostě smyčka 0-15, a počítá se hammingova váha.

2) Je třeba zajistit, aby tahy které pokryjí sousední čtverce, nastavovaly společnou hranu stejně. Tohle řeším pomocí optional constraints, podobně jako v 8-queens. Každý tah na každém čtverci jednak pokryje tento čtverec, a dál pokryje optional constraint pro svou "jižní" a "východní" stranu. "Severní" a "západní" hrana je ale 1) přesunuta do sousedícího čtverce, 2) negována. Díky tomu by v případě že by sousední čtverce nastavovaly společnou hranu na opačnou hodnotu, díky této negaci sdílely stejný optional constraint, a tím jsou tyto tahy eliminovány.

3) Správné řešení má mít jen jednu smyčku. Proto jsem ještě zavedl omezení na počet hran, které se mohou potkat ve vrcholech čtverců. Aby se zamezilo větvení a křížení, každý vrchol může mít právě 2 nebo právě 0 hran.

Tohle jsem zatím trochu odbyl, a řeším to až po výběru tahu jeho validací, a zahozením v případě že by a) zvýšil počet hran vedoucích do některého z 4 vrcholů na 3, nebo b) pokrývá poslední hranu do některého vrcholu, a nastavuje ji na jedničku. Tohle je složitější, musí se kvůli tomu ještě testovat na okraj hracího pole.

Přemýšlím že bych ten kód místo do verifikace tahu změnil na udržování invariantu, že všechny dostupné tahy jsou OK, a když některý čtverec pokryju, tak prořežu volné tahy pro ostatní čtverce (a samozřejmě strčím je na stack, a při backtracku je zase obnovím). Tohle se pro Kakuro velice osvědčilo, a urychlilo to řešení fakt dost.

4) První 3 možnosti řeší lokální vlastnosti řešení, ale správné řešení má být jedna uzavřená smyčka. Tahle verifikace není úplně triviální na naprogramování, a zatím jsem ji ani nenapsal. Místo jednoho správného řešení se mi proto vygeneruje i cca 2-5 dalších, které ale taky vypadjí zajímavě, a to správné pořád snadno vyberu.

Otevřené otázky:

* Má smysl přepisovat test na spojitost (bod 3)? na prožezávání? Má smysl testovat řešení že obsahuje pouze jednu smyčku (bod 4)?

* Nejsem si jistý jestli ten test na spojitost nečistí stavový prostor víc, než samotné omezení na počet hran u čtverce. Jestli jo, asi by bylo lepší postupovat opačným směrem- pokrývat tahy vrcholy tak, že pro každý vrchol bude právě 7 možností jak jej pokrýt- buď bude vrchol holý (1 možnost), nebo pokytý dvěma hranami (6 možností). Při pokrývání by se počítaly hrany po obvodech čtverců, a verifikovalo/prožezávalo by se podle toho teprve dodatečně.

* Úplně jiné řešení: Nebudou se vůbec generovat "hrany", budu přímo "barvit" čtverce na 2 možné barvy. Hrany budou definovány implicitně, kde se stýkají rozdílné barvy, bude hrana. Tohle vypadá lákavě, protože pro každý čtverec jsou jen 2 možné tahy, takže stavový prostor je nejmenší. Jenže zase by to povolovalo "šachovnicové" vzory, které jsou ve správných řešeních zakázány, tohle by bylo potřeba explicitně testovat a vyhazovat.. Imlementace by jinak byla podobná jako u pokrývání vrcholů- verifikace/prožezávání podle počtu hran kolem každého čtverce..

Možná je ještě nějaké další dobré řešení? Preferuji jednoduchost a eleganci i mírně na úkor efektivity.        

Komentáře

[vlastikroot]

Díky, to puzzle vypadá dobře