Lute/reification step4 testing ast

[lute47lillo]

SymbolicTerm to Function Transformer.

Tests still needed to verify all working.

[lute47lillo]

@jorgefandinno Okay, I've found some problems with how we are parsing strong negated and negated atoms when using reification. I just realized the issue of using "-" + name on the reify strong negation. Now, the expected program is an UnaryOperator, but the parsed program returns a function of name "-a" which I believe is incorrect.

I believe that I'll have to make some changes on top of the previous reification changes to do it correctly, and to test for equal programs instead of strings.

[jorgefandinno]

It makes sense

…

On Fri, Sep 9, 2022 at 10:28 Lute Lillo ***@***.***> wrote: @jorgefandinno <https://github.com/jorgefandinno> Okay, I've found some problems with how we are parsing strong negated and negated atoms when using reification. I just realized the issue of using "-" + name on the reify strong negation. Now, the expected program is an UnaryOperator, but the parsed program returns a function of name "-a" which I believe is incorrect. I believe that I'll have to make some changes on top of the previous reification changes to do it correctly, and to test for equal programs instead of strings. — Reply to this email directly, view it on GitHub <#39 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADF3ZUXKMMM3QBRK4PR6JEDV5NJRJANCNFSM6AAAAAAQHFY3SY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[lute47lillo]

I've finally solved that issue when using reification. The problem was the declaration of the name "-a" of the Function when it should have been an UnaryOperation that had an ast.Function as argument with the name "a".

[lute47lillo]

But, now I'm trying to figure out some issues for the asserting case of the lists being equal. While they are equal, they are being ordered in the wrong order and that is causing tests to fail. I'll look into it tomorrow

[lute47lillo]

Specially, I've seen it happening here. The tests with a #Fail above are the ones facing this issue. The rest of the tests are passing.

[jorgefandinno]

How are each of them ordered?

[lute47lillo]

[lute47lillo]

There you can see how the sorted program (which is the reference correctly parsed program) first has the rule not1(u(a)) :- ... while the expected program (The one we are parsing from the expected string) has the conditional Literal first

[lute47lillo]

The first part of the tests that were failing due to the bug are now failing.

However, I'm having some issues with these ones:

eclingo/tests/test_reification.py

Lines 215 to 238 in facbdc1

	def test_weighted_rules(self):
	self.assert_equal_program(
	parse_program(":-{a} = 0."),
	":-{u(a)} = 0."
	)
	def test_parameters01(self):
	self.assert_equal_program(
	parse_program("a(1..n).", ["n"], "parametrized"),
	"#program parametrized(n). u(a(1..n)).",
	)
	def test_parameters02(self):
	self.assert_equal_program(
	parse_program("a(1..n).", ["n"], "base"), "#program base(n). u(a(1..n))."
	)
	def test_heuristic(self):
	self.assert_equal_program(
	parse_program("#heuristic a. [1,sign]", [], "base"),
	"#heuristic u(a). [1,sign]",
	)
	'''

I'll check them later, but it may have something to do with the newly introduced transformer.

Pylint is also failing, but I do not see where the error is.

[lute47lillo]

For the tests:

def test_parameters01(self):
self.assert_equal_program(
parse_program("a(1..n).", ["n"], "parametrized"),
"#program parametrized(n). u(a(1..n)).",
)

 def test_parameters02(self): 
     self.assert_equal_program( 
         parse_program("a(1..n).", ["n"], "base"), "#program base(n). u(a(1..n))." 
     ) 

I'm getting another error, which the sorted program evaluates the Interval 1..n, as being Symbolic term of number 1 and another Symbolic term of a clingo Function with name 'n'.

However, the way the Transformer is set, is that the 2nd Symbolic term is being transformed to an AST.Function of name 'n' and therefore failing the test.

[lute47lillo]

For the tests:

def test_parameters01(self): self.assert_equal_program( parse_program("a(1..n).", ["n"], "parametrized"), "#program parametrized(n). u(a(1..n)).", )

 def test_parameters02(self): 
     self.assert_equal_program( 
         parse_program("a(1..n).", ["n"], "base"), "#program base(n). u(a(1..n))." 
     ) 

I'm getting another error, which the sorted program evaluates the Interval 1..n, as being Symbolic term of number 1 and another Symbolic term of a clingo Function with name 'n'.

However, the way the Transformer is set, is that the 2nd Symbolic term is being transformed to an AST.Function of name 'n' and therefore failing the test.

The idea I've had is to create another visit_Interval after this Transformer is being parsed and re-do the conversion of the interval components to Symbolic Terms,

would that work?