Verhältnis positiver und negativer Literale bei Formelgenerierung steuern lassen #274
Conversation
|
Vielleicht sollte statt eines exakten Verhältnisses mit einem Range gearbeitet werden. Analog zu Line 295 in bf6654d Dann würde sich die Notwendigkeit des "Snappens" erübrigen. Es müsste dann vielleicht sichergestellt werden (durch Überprüfung im Config-Checker), dass besagter Range nicht zu klein gewählt wird (so dass schlimmstenfalls gar kein Wert innerhalb des Ranges möglich ist; bin mir gerade nicht sicher, ob bei den Gegebenenfalls wäre Verwendung (nach geeigneter Generalisierung) von für Verwendung mit |
|
Aside: #275 |
|
Das Verhältnis wird jetzt über ein Intervall gesteuert. genericWithRatio ist eine Weiterentwicklung von withRatio, wegen zyklischer Imports aber in Formula.Types und nicht in Util. Statt (Int, Int) wird RatioMode benutzt, um zu bestimmen, welches Verhältnis geprüft werden soll.
|
Ich denke, die Range kann nicht zu klein sein. Durch die Verwendung von Damit ist die untere Grenze immer kleiner gleich der oberen Grenze, solange die Werte in der Range aufsteigend sind. Im schlimmsten Fall ist demnach die obere Grenze und die untere Grenze gleich, was dem vorherigen Fall mit dem konkreten Verhältnis entspricht. Es muss also nur darauf geachtet werden, dass die Range zwischen 0 und 100 ist und die erste Zahl kleiner gleich die zweite Zahl ist. Nur die Bennenung mit |
|
Okay, also die Sorge
aus #275 trifft nicht in genau der Form zu, sondern die 2 und 3 Prozent von 16 würden beide auf 0 abgerundet und dann nach einer Formel gesucht, in der genau 0 Einträge True sind. Ergo könnte das "schlimmstenfalls gar kein Wert innerhalb des Ranges [existent]" nicht eintreten, aber ein "besagter Range zu klein" bzw. "schlimmstenfalls gar kein Wert innerhalb des Ranges möglich" durchaus, im Sinne, dass es vielleicht (wegen anderer Constraints) gar nicht möglich ist, eine Formel zu erwürfeln, die immer zu False auswertet. Wenn dem so ist, müsste "2 bis 3 Prozent bei 16 Einträgen" eben doch verboten werden, damit die Suche nach einer alle Constraints erfüllenden Formel nicht scheitert. |
|
Eine mögliche "Heuristik" wäre (hier und in #275), die Größe der "Grundgesamtheit" (im Beispiel die Zahl 16) mit heranzuziehen bei der Beurteilung (im Config-Checker), ob ein gewisses Intervall zugelassen werden soll; und dann zu fordern, dass die Auswahl zwischen mindestens zwei verschiedene Werten besteht. (Etwa: bei 16 darf man |
…iterale Master changes
Umbenennungen, configCheker
src/Formula/Types.hs
Outdated
|
|
||
| import Data.List(intercalate, delete, nub, transpose, (\\)) | ||
| import Data.List(intercalate, delete, nub, transpose, (\\)) -- minimumBy | ||
| -- import Data.Ord(comparing) |
There was a problem hiding this comment.
Solche Zeilen/Diff-Anteile könnten noch weg. Auch weiter unten.
src/Formula/Types.hs
Outdated
|
|
||
| class Formula a where | ||
| literals :: a -> [Literal] | ||
| duplicateLiterals :: a -> [Literal] |
There was a problem hiding this comment.
Irgendwie habe ich das Gefühl, dass die API hier nicht gut ist, wenn wir sowohl literals als auch duplicateLiterals im Angebot haben.
Das eine ist ja immer eine "Obermenge" (bzw. eben Multimenge) des anderen.
Wie wäre es mit einem Refactoring:
- Es gibt nur noch eine von den beiden Funktionen; sie heißt
literalsaber hat die Semantik desduplicateLiterals. - An allen vorherigen Stellen, an denen
literalsverwendet wurde, wird ein Aufruf vonnub(odernubOrdodernubSort, was gerade passt) hinzugefügt. Bzw. auf ihn kann auch verzichtet werden, wenn klar ist, dass an der Stelle keine Duplikate vorliegen können (etwa wegen der konkreten Art vonFormula, auf der dortliteralsaufgerufen wurde) oder das Vorliegen von Duplikaten kein Problem wäre (zum Beispiel falls die Liste nur auf Leerheit getestet wird oder so).
src/Formula/Types.hs
Outdated
| -- The used atomic formulas are drawn from the list of chars. | ||
| -- The ratio must be between 0 and 1; otherwise, it will be ignored. | ||
| genCnfWithPercentRange :: PercentRangeMode -> (Int,Int) -> (Int,Int) -> [Char] -> Bool -> Gen Cnf | ||
| genCnfWithPercentRange percentPosLiterals (minNum,maxNum) (minLen,maxLen) atoms enforceUsingAllLiterals = do |
There was a problem hiding this comment.
Der Variablenname percentPosLiterals hier ist merkwürdig, da der PercentRangeMode ja auch anders ausgeprägt sein könnte.
Tritt bei mindestens einer anderen Funktion unten nochmal auf.
src/Formula/Types.hs
Outdated
| -- | Generates a random dnf satisfying the given bounds | ||
| -- for the amount and the length of the contained conjunctions. | ||
| -- for the amount and the length of the contained conjunctions, | ||
| -- as well as the ratio of negative literals. |
There was a problem hiding this comment.
Isn't it positive literals that are constrained now?
There was a problem hiding this comment.
Auch anderswo falsch beschrieben.
|
|
||
| -- | Generates a random dnf satisfying the given bounds | ||
| -- for the amount and the length of the contained conjunctions. | ||
| -- The used atomic formulas are drawn from the list of chars. |
There was a problem hiding this comment.
Wurden hier die Dokumentationen von genDnf und genDnfWithPercentRange verwechselt?
| let | ||
| allLiterals = duplicateLiterals form | ||
| posLiterals = filter isPositive allLiterals | ||
| in (length posLiterals, length allLiterals, bounds) |
There was a problem hiding this comment.
Ich fürchte, dass ich nicht ganz verstehe, wie das hier funktioniert bzw. ob es korrekt ist.
Zum Beispiel wundert mich, dass die Variable posLiteralsNumber in dem einen Fall an length trueEntries gebunden wird. Das scheint mir unlogisch.
…ver-und-negativer-Literale
literals von Formula gibt jetzt auch die Duplikate aus (fmidue#274 (comment))
Deleting duplicateLiterals
…-pos-und-neg-Lit-loc
…ltnis-pos-und-neg-Lit-loc
3 participants
CLOSE #219
Neues Feld negLiteralRatio in NormalFormConfig steuert den prozentualen Anteil der negativen Literale in der Formel.
Neue Funktionen:
Bereits integriert in genCnf' und genDnf'.
Der angegebene Anteil wird an den nächstmöglichen Anteil angenähert, damit immer eine Formel generiert werden kann, die die Bedingung erfüllt. Beispielsweise eine Formel mit 9 Literalen und einem gewünschten Anteil von 30 % wird auf 1/3 (≈ 33 %) geprüft.
Ist der angegebene Anteil außerhalb des Intervalls [0, 1], wird eine zufällige Formel generiert.