details

property	value
status	complete
benchmark	h17.xml
ran by	Akihisa Yamada
cpu timeout	1200 seconds
wallclock timeout	300 seconds
memory limit	137438953472 bytes
execution host	n140.star.cs.uiowa.edu
space	Hamana_Kikuchi_18

run statistics

property	value
solver	Wanda 2.2a
configuration	default
runtime (wallclock)	0.275721 seconds
cpu usage	0.274122
user time	0.240232
system time	0.03389
max virtual memory	113188.0
max residence set size	9656.0

stage attributes

key	value
starexec-result	YES

output

YES We consider the system theBenchmark. Alphabet: cons : [] --> a -> alist -> alist map : [] --> (a -> a) -> alist -> alist nil : [] --> alist o : [] --> (a -> a) -> (a -> a) -> a -> a Rules: map (/\x.f x) nil => nil map (/\x.f x) (cons y z) => cons (f y) (map (/\u.f u) z) map (/\x.f x) (map (/\y.g y) z) => map (/\u.o (/\v.f v) (/\w.g w) u) z o (/\x.f x) (/\y.g y) z => f (g z) Using the transformations described in [Kop11], this system can be brought in a form without leading free variables in the left-hand side, and where the left-hand side of a variable is always a functional term or application headed by a functional term. We now transform the resulting AFS into an AFSM by replacing all free variables by meta-variables (with arity 0). This leads to the following AFSM: Alphabet: cons : [a * alist] --> alist map : [a -> a * alist] --> alist nil : [] --> alist o : [a -> a * a -> a * a] --> a ~AP1 : [a -> a * a] --> a Rules: map(/\x.~AP1(F, x), nil) => nil map(/\x.~AP1(F, x), cons(X, Y)) => cons(~AP1(F, X), map(/\y.~AP1(F, y), Y)) map(/\x.~AP1(F, x), map(/\y.~AP1(G, y), X)) => map(/\z.o(/\u.~AP1(F, u), /\v.~AP1(G, v), z), X) o(/\x.~AP1(F, x), /\y.~AP1(G, y), X) => ~AP1(F, ~AP1(G, X)) map(/\x.o(F, G, x), nil) => nil map(/\x.o(F, G, x), cons(X, Y)) => cons(o(F, G, X), map(/\y.o(F, G, y), Y)) map(/\x.o(F, G, x), map(/\y.~AP1(H, y), X)) => map(/\z.o(/\u.o(F, G, u), /\v.~AP1(H, v), z), X) map(/\x.~AP1(F, x), map(/\y.o(G, H, y), X)) => map(/\z.o(/\u.~AP1(F, u), /\v.o(G, H, v), z), X) o(/\x.o(F, G, x), /\y.~AP1(H, y), X) => o(F, G, ~AP1(H, X)) o(/\x.~AP1(F, x), /\y.o(G, H, y), X) => ~AP1(F, o(G, H, X)) map(/\x.o(F, G, x), map(/\y.o(H, I, y), X)) => map(/\z.o(/\u.o(F, G, u), /\v.o(H, I, v), z), X) o(/\x.o(F, G, x), /\y.o(H, I, y), X) => o(F, G, o(H, I, X)) ~AP1(F, X) => F X Symbol ~AP1 is an encoding for application that is only used in innocuous ways. We can simplify the program (without losing non-termination) by removing it. Additionally, we can remove some (now-)redundant rules. This gives: Alphabet: cons : [a * alist] --> alist map : [a -> a * alist] --> alist nil : [] --> alist o : [a -> a * a -> a * a] --> a Rules: map(/\x.X(x), nil) => nil map(/\x.X(x), cons(Y, Z)) => cons(X(Y), map(/\y.X(y), Z)) map(/\x.X(x), map(/\y.Y(y), Z)) => map(/\z.o(/\u.X(u), /\v.Y(v), z), Z) o(/\x.X(x), /\y.Y(y), Z) => X(Y(Z)) We use the dependency pair framework as described in [Kop12, Ch. 6/7], with static dependency pairs (see [KusIsoSakBla09] and the adaptation for AFSMs and accessible arguments in [FuhKop19]). We thus obtain the following dependency pair problem (P_0, R_0, computable, formative): Dependency Pairs P_0: 0] map#(/\x.X(x), cons(Y, Z)) =#> map#(/\y.X(y), Z) 1] map#(/\x.X(x), map(/\y.Y(y), Z)) =#> map#(/\z.o(/\u.X(u), /\v.Y(v), z), Z) 2] map#(/\x.X(x), map(/\y.Y(y), Z)) =#> o#(/\z.X(z), /\u.Y(u), U) Rules R_0: map(/\x.X(x), nil) => nil map(/\x.X(x), cons(Y, Z)) => cons(X(Y), map(/\y.X(y), Z)) map(/\x.X(x), map(/\y.Y(y), Z)) => map(/\z.o(/\u.X(u), /\v.Y(v), z), Z) o(/\x.X(x), /\y.Y(y), Z) => X(Y(Z)) Thus, the original system is terminating if (P_0, R_0, computable, formative) is finite. We consider the dependency pair problem (P_0, R_0, computable, formative). We place the elements of P in a dependency graph approximation G (see e.g. [Kop12, Thm. 7.27, 7.29], as follows: * 0 : 0, 1, 2 * 1 : 0, 1, 2 * 2 : This graph has the following strongly connected components: P_1: map#(/\x.X(x), cons(Y, Z)) =#> map#(/\y.X(y), Z) map#(/\x.X(x), map(/\y.Y(y), Z)) =#> map#(/\z.o(/\u.X(u), /\v.Y(v), z), Z) By [Kop12, Thm. 7.31], we may replace any dependency pair problem (P_0, R_0, m, f) by (P_1, R_0, m, f). Thus, the original system is terminating if (P_1, R_0, computable, formative) is finite. We consider the dependency pair problem (P_1, R_0, computable, formative). popout

output may be truncated. 'popout' for the full output.

job log

popout

actions

all output return to Higher Order Rewriting Union Beta