<p>Das Programm löst das Problem in Brute-Force-Methode.
Die brauchbare Geschwindigkeit von zumeist < 1 s
kommt von der Kodierung der Puzzleteile als 64-Bit-Zahl
und der damit ausgeführten booleschen Verknüpfungen.
Denn das Zielgebiet ist max. 7×7 „Pixel“ groß,
hier als 8×8 kodiert.
Die linke obere Ecke ist Bit 0.
Rechtsschieben des Puzzleteils entspricht
1-Bit-Linksschieben der 64-Bit-Zahl,
gefüllte Spalten Nr. 7 entsprechen ungültige Positionen.
Nach-unten-schieben des Puzzleteils entspricht
8-Bit-Linksschieben,
Bits in Zeile 7 bzw. Zeile 6 ab Spalte 3
beenden den Probieralgorithmus für dieses Puzzleteil.
<p>Als Ausgangspunkt für mein Programm dient ein
hölzernes Puzzle mit Maserung.
Die Form der Teile, in der Reihenfolge der Implementierung
im Programm:
<pre>
0 1 2 3 4 5 6 7
xxx xx xxxx xx xx x x x
xxx xxx xx x x x xx x
xx xx xxx x x
x xx
</pre>
Die Maserung ist dabei senkrecht.
Da die Teile maximal 4×4 groß sind genügt für ihre
Kodierung eine 16-Bit-Zahl als Bitmap, 1 Nibble pro Zeile.
Im Gegensatz zur gängigen (?) Kodierung von Bitmaps
hier mit Bit 0 in der linken Spalte, das ist handlicher.
<p>Erst später bin ich darauf gekommen, dass es sich um ein
weltbekanntes Puzzle mit der Bezeichnung
„A Puzzle A Day“ handelt.
<p>Das Programm hat folgende Schwächen: <ul>
<li> Algorithmus nicht registeroptimiert
<li> Findet nicht alle Lösungen
<li> Bevorzugt nicht automatisch Lösungen ohne Rückseiten der Puzzleteile
<li> Nicht im Thread
<li> Keine Anzeige der Rechenzeit
<li> Keine freie Datumseingabe
<li> Keine Visualisierung der Maserung
<li> Keine Visualisierung der Kontur der Puzzleteile als Polygon
(Das macht übrigens keines der gesehenen Programme!)
<li> Plumpe Bedienung
</ul>
<p>Und folgende Stärken: <ul>
<li> Monatsnamen in Windows-Sprache
<li> Startet mit aktuellem Datum
<li> Erlaubnis für umgedrehte Puzzleteile auswählbar
<li> Fenster und Lösung größeneinstellbar, Bildseitenverhältnis 1:1
<li> Speicherung Fenserposition und -größe
</ul>
henni, 231102
| Detected encoding: UTF-8 | 0
|