Entwicklung und Implementierung von Heuristiken zur optimierten ...

( deposit belt“) kommt, und schon bei dieser Aufgabe liefert die Breitensuche kein
”
Ergebnis trotz 900 MB Speicher und das Ergebnis der Tiefensuche ist mit 777.09
Sekunden sehr viel schlechter als mit Heuristiken. Sobald allerdings die Heuristik
des Abstands zum Fehlerzustand UPPAAL CORA als Wert für heur übergeben
wird, findet die Suche smallest heur first“, die den Pfad des kleinsten Wertes von
”
heur als Erstes verfolgt, einen Ablauf in gut 20 Sekunden. heur wird in diesem Fall
berechnet, wie in Kapitel 5.3 beschrieben, wobei der Werkstück-Automat derjenige
ist, dessen Zielzustand wir kennen. Die randomisierte Tiefensuche liefert zwar nach,
im Vergleich guten, 30,53 Sekunden im Schnitt ein Ergebnis, allerdings bleibt ein
Versuch erfolglos.
C 1 C 2 C 3 bf df rdf 4 shf bf (c+r) rbdf (c+r)
0 0 10 21.63 22.03 21.32
0 1 10 22.03 19.68 19.28
1 0 10 21.83 22.14 20.92
1 1 10 k.A. 5 777.09 30.53 6 22.75 19.92 19.48
0 0 10* 40.81 41.53 21.01
0 1 10* 1068.65 21.73 19.69
1 0 10* 40.91 40.33 20.91
1 1 10* 1063.52 21.84 19.49
Tabelle 4: Evaluation mit einem Blech im System (mit Ziel: end db)
Die Optimierungsidee, pro Variable, die den gewünschten Wert hat, um eine Kante
zu nehmen, den heuristischen Wert weiter zu reduzieren (gekennzeichnet durch
* in der Spalte C 3 ), erweist sich hier übrigens als kontraproduktiv, da die Zeiten
hierbei um 40 Sekunden liegen. Sowohl bei der Suche bf als auch bei ”
randomdepth-best-first“
wurde remaining der gleiche Wert wie heur zugeordnet, deswegen
überrascht es kaum, dass die Ergebnisse bei diesen Suchen ähnlich um 20 Sekunden
liegen wie bei der Suche bf.
Die Hinzunahme von Kosten für einen Zyklus führt zu keiner relevanten Verbesserung,
aber bei den Suchen bf und rdbf macht sich das Erhöhen der Kosten
4 Es wird ein Durchschnittswert von zehn Versuchen angegeben.
5 Nach ca. 40 Minuten war der zugesicherte Speicher von 900 MB aufgebraucht.
6 Ein Versuch blieb bei vorgesehenem Speicher von 900 MB erfolglos.
36