Functions and aggregates
GraphFuncsAndAggregates zou nog slimmere dingen moeten doen denk ik.
Ik had een theorie die heel gemakkelijk (fractie van een seconde) op te lossen was. Na het toevoegen van een nieuwe functie Places(table) : {0..20} die enkel diende om de output leesbaarder te maken, dus een functie die volledig bepaald werd door
!table[Table]: #{guest: SitsAt(guest)=table} = Places(table).
ontplofte mijn grounding en werd het probleem haast onoplosbaar. Dit zou niet mogen...
Comments (5)
-
-
reporter Neen. De reden waarom ik dit heb ingevoerd is om gemakkelijkere theorieen te schrijven. Bijvoorbeeld:
!t[Table]: (MinTableSize =< #{guest: SitsAt(guest)=t} =< MaxTableSize)
#{guest: SitsAt(guest)=t} = 0. Werd
!t[Table]: (MinTableSize =<Places(t) =< MaxTableSize)
Places(t) = 0. Dit ligt misschien niet meteen aan het graphen, maar het is wel het graphen dat extra variabelen invoert. Dit zou ook natuurlijk kunnen liggen aan een gebrek aan cp. Want met #{...} =< ... gebeurt iets slim, maar met f(x) =< ... niet (wordt naief geground)
Ik geloof zelfs dat er soms fouten in slopen (unsat waar dat niet mocht), maar dit zou ook aan een combinatie met de symmetriebreking kunnen gelegen hebben (ik moet het nog eens goed nakijken)
-
- changed milestone to Later
-
- changed status to wontfix
-
- removed milestone
Removing milestone: Later (automated comment)
- Log in to comment
(Reply via broe...@gmail.com):
Ik zie niet meteen waarom het ligt aan het graphen?
Is dat niet iets dat je zou willen oplossen door meerdere keren mx te doen?
Broes
2012/5/14 Bart Bogaerts <issues-reply@bitbucket.org>