Functions and aggregates

[Bart Bogaerts]

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...

[Broes De Cat]

(Reply via [e-mail]):

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 <[e-mail]>

[Bart Bogaerts]

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)

[Broes De Cat]

Opgesplitst in twee kleinere bugs (#304 en #305)

[Broes De Cat]

Removing milestone: Later (automated comment)