Approximation bug

[Broes De Cat]

ASSERT FAILED: getDomain(connector)._twovalued

Lijkt verband te houden met het uitrekenen van gedefinieerde functies door XSB.

Correctie: lijkt toch niet verband te hebben met XSB (of anders meerdere bugs).

procedure main(){ stdoptions.xsb=false calculatedefinitions(solution,S) }

crasht ook op approximatie

Correctie op de correctie: lijkt toch wel verband te houden met XSB (zie lager)

[Bart Bogaerts]

Waarschijnlijk heeft dit te make nmet de missende totality check voor functies bij gebruik van xsb.

Zie: #507

(die geeft toch dezelfde assert die faalt en in release is xsb daar gewoon mis...)

[Bart Bogaerts]

Het probleem met die laatste opmerking is dat calculatedefinitions te weinig checks doet op vocabularium van zijn input. En daarna zelf een theorie opbouwt over een te klein vocabularium (hij gebruikt symbolen in de theorie die niet in voc zitten)

Dit is gefixed ondertussen (commit komt eraan)

Het echte probleem bij deze bug is volgens mij nog steeds de ontbrekende totality check op functies indien xsb aanstaat, dus ik geef de issue terug door naar Joachim

[Bart Bogaerts]

added missing checks on vocabularies, see #456

→ <<cset c094c77d9f92>>

[Joachim Jansen]

Is this still relevant? What is this about?

[Broes De Cat]

quote iets hoger in de history: Het echte probleem bij deze bug is volgens mij nog steeds de ontbrekende totality check op functies indien xsb aanstaat, dus ik geef de issue terug door naar Joachim

[Bart Bogaerts]

Nog steeds relevant.. . Nu wordt er een error gegooid ipv een assert fie faalt, maar onderliggend probleem is waarschijnlijk dat er een totality check op uitgerekende functies ontbreekt in xsb... Dat was toen toch mijn gok... Run de file eens met xsb en check of hij correct is

[Bart Bogaerts]

Als je de file (op master geloof ik) met xsb runt, en calculatedefintions(solutions,S) uitvoert, krijg je nu: geen oplossingen.

Dus...Ofwel zit er nog een fout in de xsb, ofwel in de modellering (komt van ASPCOMP)

[Broes De Cat]

Maar geeft het een ander resultaat als je xsb afzet? Dan zit het sowieso in de code, nee?

[Bart Bogaerts]

loopt nogal lang zonder xsb.

xsb=instant unsat van de definities...

[Broes De Cat]

Zonder xsb zat er een hardgecodeerd type int in, oneindige grounding dus. Heb die eruit gehaald en dan is het niet unsat zonder xsb. Met die aangepaste regel, nbUnusedNodes vervangen door de cardinaliteit zelf overal, crasht xsb (op de huidige master). Bug(s) in XSB dus.

[Joachim Jansen]

XSB: Changed a check when handling aggregates.

Since we want the resulting type to be able to be int, we want to check the var AFTER the unification and not before (so it is an output var, not an input var)

This fixes bug #456

→ <<cset c66680949d9c>>

[Joachim Jansen]

XSB: Changed a check when handling aggregates.

Since we want the resulting type to be able to be int, we want to check the var AFTER the unification and not before (so it is an output var, not an input var)

This fixes bug #456

→ <<cset 7f785c6f2daa>>

[Joachim Jansen]

XSB: Changed a check when handling aggregates.

Since we want the resulting type to be able to be int, we want to check the var AFTER the unification and not before (so it is an output var, not an input var)

This fixes bug #456

→ <<cset 5a9fe17aac83>>

[Joachim Jansen]

XSB: Changed a check when handling aggregates.

Since we want the resulting type to be able to be int, we want to check the var AFTER the unification and not before (so it is an output var, not an input var)

This fixes bug #456

→ <<cset 3abde6482c48>>

[Joachim Jansen]

XSB: Changed a check when handling aggregates.

Since we want the resulting type to be able to be int, we want to check the var AFTER the unification and not before (so it is an output var, not an input var)

This fixes bug #456

→ <<cset cd9e937d5434>>

[Joachim Jansen]

XSB: Changed a check when handling aggregates.

Since we want the resulting type to be able to be int, we want to check the var AFTER the unification and not before (so it is an output var, not an input var)

This fixes bug #456

→ <<cset ab3eab7e9318>>

[Joachim Jansen]

XSB: Changed a check when handling aggregates.

Since we want the resulting type to be able to be int, we want to check the var AFTER the unification and not before (so it is an output var, not an input var)

This fixes bug #456

→ <<cset 436ee0c97d16>>

[Joachim Jansen]

XSB: Changed a check when handling aggregates.

Since we want the resulting type to be able to be int, we want to check the var AFTER the unification and not before (so it is an output var, not an input var)

This fixes bug #456

→ <<cset 880348b94291>>