Tool CaT
Execution Time | Unknown |
---|
Answer | MAYBE |
---|
Input | SK90 2.18 |
---|
stdout:
MAYBE
Problem:
sum(0()) -> 0()
sum(s(x)) -> +(sum(x),s(x))
+(x,0()) -> x
+(x,s(y)) -> s(+(x,y))
Proof:
OpenTool IRC1
Execution Time | Unknown |
---|
Answer | MAYBE |
---|
Input | SK90 2.18 |
---|
stdout:
MAYBE
Tool IRC2
Execution Time | Unknown |
---|
Answer | MAYBE |
---|
Input | SK90 2.18 |
---|
stdout:
MAYBE
'Fastest (timeout of 60.0 seconds)'
-----------------------------------
Answer: MAYBE
Input Problem: innermost runtime-complexity with respect to
Rules:
{ sum(0()) -> 0()
, sum(s(x)) -> +(sum(x), s(x))
, +(x, 0()) -> x
, +(x, s(y)) -> s(+(x, y))}
Proof Output:
None of the processors succeeded.
Details of failed attempt(s):
-----------------------------
1) 'wdg' failed due to the following reason:
Transformation Details:
-----------------------
We have computed the following set of weak (innermost) dependency pairs:
{ 1: sum^#(0()) -> c_0()
, 2: sum^#(s(x)) -> c_1(+^#(sum(x), s(x)))
, 3: +^#(x, 0()) -> c_2()
, 4: +^#(x, s(y)) -> c_3(+^#(x, y))}
Following Dependency Graph (modulo SCCs) was computed. (Answers to
subproofs are indicated to the right.)
->{2} [ inherited ]
|
`->{4} [ inherited ]
|
`->{3} [ MAYBE ]
->{1} [ YES(?,O(1)) ]
Sub-problems:
-------------
* Path {1}: YES(?,O(1))
---------------------
The usable rules of this path are empty.
The weightgap principle applies, using the following adequate RMI:
The following argument positions are usable:
Uargs(sum) = {}, Uargs(s) = {}, Uargs(+) = {}, Uargs(sum^#) = {},
Uargs(c_1) = {}, Uargs(+^#) = {}, Uargs(c_3) = {}
We have the following constructor-restricted matrix interpretation:
Interpretation Functions:
sum(x1) = [0 0 0] x1 + [0]
[0 0 0] [0]
[0 0 0] [0]
0() = [0]
[0]
[0]
s(x1) = [0 0 0] x1 + [0]
[0 0 0] [0]
[0 0 0] [0]
+(x1, x2) = [0 0 0] x1 + [0 0 0] x2 + [0]
[0 0 0] [0 0 0] [0]
[0 0 0] [0 0 0] [0]
sum^#(x1) = [0 0 0] x1 + [0]
[0 0 0] [0]
[0 0 0] [0]
c_0() = [0]
[0]
[0]
c_1(x1) = [0 0 0] x1 + [0]
[0 0 0] [0]
[0 0 0] [0]
+^#(x1, x2) = [0 0 0] x1 + [0 0 0] x2 + [0]
[0 0 0] [0 0 0] [0]
[0 0 0] [0 0 0] [0]
c_2() = [0]
[0]
[0]
c_3(x1) = [0 0 0] x1 + [0]
[0 0 0] [0]
[0 0 0] [0]
We apply the sub-processor on the resulting sub-problem:
'matrix-interpretation of dimension 3'
--------------------------------------
Answer: YES(?,O(1))
Input Problem: innermost DP runtime-complexity with respect to
Strict Rules: {sum^#(0()) -> c_0()}
Weak Rules: {}
Proof Output:
The following argument positions are usable:
Uargs(sum^#) = {}
We have the following constructor-restricted matrix interpretation:
Interpretation Functions:
0() = [2]
[2]
[2]
sum^#(x1) = [0 2 0] x1 + [7]
[2 2 0] [3]
[2 2 2] [3]
c_0() = [0]
[1]
[1]
* Path {2}: inherited
-------------------
This path is subsumed by the proof of path {2}->{4}->{3}.
* Path {2}->{4}: inherited
------------------------
This path is subsumed by the proof of path {2}->{4}->{3}.
* Path {2}->{4}->{3}: MAYBE
-------------------------
The usable rules for this path are:
{ sum(0()) -> 0()
, sum(s(x)) -> +(sum(x), s(x))
, +(x, 0()) -> x
, +(x, s(y)) -> s(+(x, y))}
The weight gap principle does not apply:
The input cannot be shown compatible
Complexity induced by the adequate RMI: MAYBE
We apply the sub-processor on the resulting sub-problem:
'matrix-interpretation of dimension 3'
--------------------------------------
Answer: MAYBE
Input Problem: innermost runtime-complexity with respect to
Rules:
{ +^#(x, s(y)) -> c_3(+^#(x, y))
, sum^#(s(x)) -> c_1(+^#(sum(x), s(x)))
, +^#(x, 0()) -> c_2()
, sum(0()) -> 0()
, sum(s(x)) -> +(sum(x), s(x))
, +(x, 0()) -> x
, +(x, s(y)) -> s(+(x, y))}
Proof Output:
The input cannot be shown compatible
2) 'wdg' failed due to the following reason:
Transformation Details:
-----------------------
We have computed the following set of weak (innermost) dependency pairs:
{ 1: sum^#(0()) -> c_0()
, 2: sum^#(s(x)) -> c_1(+^#(sum(x), s(x)))
, 3: +^#(x, 0()) -> c_2()
, 4: +^#(x, s(y)) -> c_3(+^#(x, y))}
Following Dependency Graph (modulo SCCs) was computed. (Answers to
subproofs are indicated to the right.)
->{2} [ inherited ]
|
`->{4} [ inherited ]
|
`->{3} [ MAYBE ]
->{1} [ YES(?,O(1)) ]
Sub-problems:
-------------
* Path {1}: YES(?,O(1))
---------------------
The usable rules of this path are empty.
The weightgap principle applies, using the following adequate RMI:
The following argument positions are usable:
Uargs(sum) = {}, Uargs(s) = {}, Uargs(+) = {}, Uargs(sum^#) = {},
Uargs(c_1) = {}, Uargs(+^#) = {}, Uargs(c_3) = {}
We have the following constructor-restricted matrix interpretation:
Interpretation Functions:
sum(x1) = [0 0] x1 + [0]
[0 0] [0]
0() = [0]
[0]
s(x1) = [0 0] x1 + [0]
[0 0] [0]
+(x1, x2) = [0 0] x1 + [0 0] x2 + [0]
[0 0] [0 0] [0]
sum^#(x1) = [0 0] x1 + [0]
[0 0] [0]
c_0() = [0]
[0]
c_1(x1) = [0 0] x1 + [0]
[0 0] [0]
+^#(x1, x2) = [0 0] x1 + [0 0] x2 + [0]
[0 0] [0 0] [0]
c_2() = [0]
[0]
c_3(x1) = [0 0] x1 + [0]
[0 0] [0]
We apply the sub-processor on the resulting sub-problem:
'matrix-interpretation of dimension 2'
--------------------------------------
Answer: YES(?,O(1))
Input Problem: innermost DP runtime-complexity with respect to
Strict Rules: {sum^#(0()) -> c_0()}
Weak Rules: {}
Proof Output:
The following argument positions are usable:
Uargs(sum^#) = {}
We have the following constructor-restricted matrix interpretation:
Interpretation Functions:
0() = [2]
[2]
sum^#(x1) = [2 0] x1 + [7]
[2 2] [7]
c_0() = [0]
[1]
* Path {2}: inherited
-------------------
This path is subsumed by the proof of path {2}->{4}->{3}.
* Path {2}->{4}: inherited
------------------------
This path is subsumed by the proof of path {2}->{4}->{3}.
* Path {2}->{4}->{3}: MAYBE
-------------------------
The usable rules for this path are:
{ sum(0()) -> 0()
, sum(s(x)) -> +(sum(x), s(x))
, +(x, 0()) -> x
, +(x, s(y)) -> s(+(x, y))}
The weight gap principle does not apply:
The input cannot be shown compatible
Complexity induced by the adequate RMI: MAYBE
We apply the sub-processor on the resulting sub-problem:
'matrix-interpretation of dimension 2'
--------------------------------------
Answer: MAYBE
Input Problem: innermost runtime-complexity with respect to
Rules:
{ +^#(x, s(y)) -> c_3(+^#(x, y))
, sum^#(s(x)) -> c_1(+^#(sum(x), s(x)))
, +^#(x, 0()) -> c_2()
, sum(0()) -> 0()
, sum(s(x)) -> +(sum(x), s(x))
, +(x, 0()) -> x
, +(x, s(y)) -> s(+(x, y))}
Proof Output:
The input cannot be shown compatible
3) 'wdg' failed due to the following reason:
Transformation Details:
-----------------------
We have computed the following set of weak (innermost) dependency pairs:
{ 1: sum^#(0()) -> c_0()
, 2: sum^#(s(x)) -> c_1(+^#(sum(x), s(x)))
, 3: +^#(x, 0()) -> c_2()
, 4: +^#(x, s(y)) -> c_3(+^#(x, y))}
Following Dependency Graph (modulo SCCs) was computed. (Answers to
subproofs are indicated to the right.)
->{2} [ inherited ]
|
`->{4} [ inherited ]
|
`->{3} [ MAYBE ]
->{1} [ YES(?,O(1)) ]
Sub-problems:
-------------
* Path {1}: YES(?,O(1))
---------------------
The usable rules of this path are empty.
The weightgap principle applies, using the following adequate RMI:
The following argument positions are usable:
Uargs(sum) = {}, Uargs(s) = {}, Uargs(+) = {}, Uargs(sum^#) = {},
Uargs(c_1) = {}, Uargs(+^#) = {}, Uargs(c_3) = {}
We have the following constructor-restricted matrix interpretation:
Interpretation Functions:
sum(x1) = [0] x1 + [0]
0() = [0]
s(x1) = [0] x1 + [0]
+(x1, x2) = [0] x1 + [0] x2 + [0]
sum^#(x1) = [0] x1 + [0]
c_0() = [0]
c_1(x1) = [0] x1 + [0]
+^#(x1, x2) = [0] x1 + [0] x2 + [0]
c_2() = [0]
c_3(x1) = [0] x1 + [0]
We apply the sub-processor on the resulting sub-problem:
'matrix-interpretation of dimension 1'
--------------------------------------
Answer: YES(?,O(1))
Input Problem: innermost DP runtime-complexity with respect to
Strict Rules: {sum^#(0()) -> c_0()}
Weak Rules: {}
Proof Output:
The following argument positions are usable:
Uargs(sum^#) = {}
We have the following constructor-restricted matrix interpretation:
Interpretation Functions:
0() = [7]
sum^#(x1) = [1] x1 + [7]
c_0() = [1]
* Path {2}: inherited
-------------------
This path is subsumed by the proof of path {2}->{4}->{3}.
* Path {2}->{4}: inherited
------------------------
This path is subsumed by the proof of path {2}->{4}->{3}.
* Path {2}->{4}->{3}: MAYBE
-------------------------
The usable rules for this path are:
{ sum(0()) -> 0()
, sum(s(x)) -> +(sum(x), s(x))
, +(x, 0()) -> x
, +(x, s(y)) -> s(+(x, y))}
The weight gap principle does not apply:
The input cannot be shown compatible
Complexity induced by the adequate RMI: MAYBE
We apply the sub-processor on the resulting sub-problem:
'matrix-interpretation of dimension 1'
--------------------------------------
Answer: MAYBE
Input Problem: innermost runtime-complexity with respect to
Rules:
{ +^#(x, s(y)) -> c_3(+^#(x, y))
, sum^#(s(x)) -> c_1(+^#(sum(x), s(x)))
, +^#(x, 0()) -> c_2()
, sum(0()) -> 0()
, sum(s(x)) -> +(sum(x), s(x))
, +(x, 0()) -> x
, +(x, s(y)) -> s(+(x, y))}
Proof Output:
The input cannot be shown compatible
4) 'matrix-interpretation of dimension 1' failed due to the following reason:
The input cannot be shown compatible
5) 'Bounds with perSymbol-enrichment and initial automaton 'match'' failed due to the following reason:
match-boundness of the problem could not be verified.
6) 'Bounds with minimal-enrichment and initial automaton 'match'' failed due to the following reason:
match-boundness of the problem could not be verified.
Tool RC1
Execution Time | Unknown |
---|
Answer | MAYBE |
---|
Input | SK90 2.18 |
---|
stdout:
MAYBE
Tool RC2
Execution Time | Unknown |
---|
Answer | MAYBE |
---|
Input | SK90 2.18 |
---|
stdout:
MAYBE
'Fastest (timeout of 60.0 seconds)'
-----------------------------------
Answer: MAYBE
Input Problem: runtime-complexity with respect to
Rules:
{ sum(0()) -> 0()
, sum(s(x)) -> +(sum(x), s(x))
, +(x, 0()) -> x
, +(x, s(y)) -> s(+(x, y))}
Proof Output:
None of the processors succeeded.
Details of failed attempt(s):
-----------------------------
1) 'wdg' failed due to the following reason:
Transformation Details:
-----------------------
We have computed the following set of weak (innermost) dependency pairs:
{ 1: sum^#(0()) -> c_0()
, 2: sum^#(s(x)) -> c_1(+^#(sum(x), s(x)))
, 3: +^#(x, 0()) -> c_2(x)
, 4: +^#(x, s(y)) -> c_3(+^#(x, y))}
Following Dependency Graph (modulo SCCs) was computed. (Answers to
subproofs are indicated to the right.)
->{2} [ inherited ]
|
`->{4} [ inherited ]
|
`->{3} [ MAYBE ]
->{1} [ YES(?,O(1)) ]
Sub-problems:
-------------
* Path {1}: YES(?,O(1))
---------------------
The usable rules of this path are empty.
The weightgap principle applies, using the following adequate RMI:
The following argument positions are usable:
Uargs(sum) = {}, Uargs(s) = {}, Uargs(+) = {}, Uargs(sum^#) = {},
Uargs(c_1) = {}, Uargs(+^#) = {}, Uargs(c_2) = {}, Uargs(c_3) = {}
We have the following constructor-restricted matrix interpretation:
Interpretation Functions:
sum(x1) = [0 0 0] x1 + [0]
[0 0 0] [0]
[0 0 0] [0]
0() = [0]
[0]
[0]
s(x1) = [0 0 0] x1 + [0]
[0 0 0] [0]
[0 0 0] [0]
+(x1, x2) = [0 0 0] x1 + [0 0 0] x2 + [0]
[0 0 0] [0 0 0] [0]
[0 0 0] [0 0 0] [0]
sum^#(x1) = [0 0 0] x1 + [0]
[0 0 0] [0]
[0 0 0] [0]
c_0() = [0]
[0]
[0]
c_1(x1) = [0 0 0] x1 + [0]
[0 0 0] [0]
[0 0 0] [0]
+^#(x1, x2) = [0 0 0] x1 + [0 0 0] x2 + [0]
[0 0 0] [0 0 0] [0]
[0 0 0] [0 0 0] [0]
c_2(x1) = [0 0 0] x1 + [0]
[0 0 0] [0]
[0 0 0] [0]
c_3(x1) = [0 0 0] x1 + [0]
[0 0 0] [0]
[0 0 0] [0]
We apply the sub-processor on the resulting sub-problem:
'matrix-interpretation of dimension 3'
--------------------------------------
Answer: YES(?,O(1))
Input Problem: DP runtime-complexity with respect to
Strict Rules: {sum^#(0()) -> c_0()}
Weak Rules: {}
Proof Output:
The following argument positions are usable:
Uargs(sum^#) = {}
We have the following constructor-restricted matrix interpretation:
Interpretation Functions:
0() = [2]
[2]
[2]
sum^#(x1) = [0 2 0] x1 + [7]
[2 2 0] [3]
[2 2 2] [3]
c_0() = [0]
[1]
[1]
* Path {2}: inherited
-------------------
This path is subsumed by the proof of path {2}->{4}->{3}.
* Path {2}->{4}: inherited
------------------------
This path is subsumed by the proof of path {2}->{4}->{3}.
* Path {2}->{4}->{3}: MAYBE
-------------------------
The usable rules for this path are:
{ sum(0()) -> 0()
, sum(s(x)) -> +(sum(x), s(x))
, +(x, 0()) -> x
, +(x, s(y)) -> s(+(x, y))}
The weight gap principle does not apply:
The input cannot be shown compatible
Complexity induced by the adequate RMI: MAYBE
We apply the sub-processor on the resulting sub-problem:
'matrix-interpretation of dimension 3'
--------------------------------------
Answer: MAYBE
Input Problem: runtime-complexity with respect to
Rules:
{ +^#(x, s(y)) -> c_3(+^#(x, y))
, sum^#(s(x)) -> c_1(+^#(sum(x), s(x)))
, +^#(x, 0()) -> c_2(x)
, sum(0()) -> 0()
, sum(s(x)) -> +(sum(x), s(x))
, +(x, 0()) -> x
, +(x, s(y)) -> s(+(x, y))}
Proof Output:
The input cannot be shown compatible
2) 'wdg' failed due to the following reason:
Transformation Details:
-----------------------
We have computed the following set of weak (innermost) dependency pairs:
{ 1: sum^#(0()) -> c_0()
, 2: sum^#(s(x)) -> c_1(+^#(sum(x), s(x)))
, 3: +^#(x, 0()) -> c_2(x)
, 4: +^#(x, s(y)) -> c_3(+^#(x, y))}
Following Dependency Graph (modulo SCCs) was computed. (Answers to
subproofs are indicated to the right.)
->{2} [ inherited ]
|
`->{4} [ inherited ]
|
`->{3} [ MAYBE ]
->{1} [ YES(?,O(1)) ]
Sub-problems:
-------------
* Path {1}: YES(?,O(1))
---------------------
The usable rules of this path are empty.
The weightgap principle applies, using the following adequate RMI:
The following argument positions are usable:
Uargs(sum) = {}, Uargs(s) = {}, Uargs(+) = {}, Uargs(sum^#) = {},
Uargs(c_1) = {}, Uargs(+^#) = {}, Uargs(c_2) = {}, Uargs(c_3) = {}
We have the following constructor-restricted matrix interpretation:
Interpretation Functions:
sum(x1) = [0 0] x1 + [0]
[0 0] [0]
0() = [0]
[0]
s(x1) = [0 0] x1 + [0]
[0 0] [0]
+(x1, x2) = [0 0] x1 + [0 0] x2 + [0]
[0 0] [0 0] [0]
sum^#(x1) = [0 0] x1 + [0]
[0 0] [0]
c_0() = [0]
[0]
c_1(x1) = [0 0] x1 + [0]
[0 0] [0]
+^#(x1, x2) = [0 0] x1 + [0 0] x2 + [0]
[0 0] [0 0] [0]
c_2(x1) = [0 0] x1 + [0]
[0 0] [0]
c_3(x1) = [0 0] x1 + [0]
[0 0] [0]
We apply the sub-processor on the resulting sub-problem:
'matrix-interpretation of dimension 2'
--------------------------------------
Answer: YES(?,O(1))
Input Problem: DP runtime-complexity with respect to
Strict Rules: {sum^#(0()) -> c_0()}
Weak Rules: {}
Proof Output:
The following argument positions are usable:
Uargs(sum^#) = {}
We have the following constructor-restricted matrix interpretation:
Interpretation Functions:
0() = [2]
[2]
sum^#(x1) = [2 0] x1 + [7]
[2 2] [7]
c_0() = [0]
[1]
* Path {2}: inherited
-------------------
This path is subsumed by the proof of path {2}->{4}->{3}.
* Path {2}->{4}: inherited
------------------------
This path is subsumed by the proof of path {2}->{4}->{3}.
* Path {2}->{4}->{3}: MAYBE
-------------------------
The usable rules for this path are:
{ sum(0()) -> 0()
, sum(s(x)) -> +(sum(x), s(x))
, +(x, 0()) -> x
, +(x, s(y)) -> s(+(x, y))}
The weight gap principle does not apply:
The input cannot be shown compatible
Complexity induced by the adequate RMI: MAYBE
We apply the sub-processor on the resulting sub-problem:
'matrix-interpretation of dimension 2'
--------------------------------------
Answer: MAYBE
Input Problem: runtime-complexity with respect to
Rules:
{ +^#(x, s(y)) -> c_3(+^#(x, y))
, sum^#(s(x)) -> c_1(+^#(sum(x), s(x)))
, +^#(x, 0()) -> c_2(x)
, sum(0()) -> 0()
, sum(s(x)) -> +(sum(x), s(x))
, +(x, 0()) -> x
, +(x, s(y)) -> s(+(x, y))}
Proof Output:
The input cannot be shown compatible
3) 'wdg' failed due to the following reason:
Transformation Details:
-----------------------
We have computed the following set of weak (innermost) dependency pairs:
{ 1: sum^#(0()) -> c_0()
, 2: sum^#(s(x)) -> c_1(+^#(sum(x), s(x)))
, 3: +^#(x, 0()) -> c_2(x)
, 4: +^#(x, s(y)) -> c_3(+^#(x, y))}
Following Dependency Graph (modulo SCCs) was computed. (Answers to
subproofs are indicated to the right.)
->{2} [ inherited ]
|
`->{4} [ inherited ]
|
`->{3} [ MAYBE ]
->{1} [ YES(?,O(1)) ]
Sub-problems:
-------------
* Path {1}: YES(?,O(1))
---------------------
The usable rules of this path are empty.
The weightgap principle applies, using the following adequate RMI:
The following argument positions are usable:
Uargs(sum) = {}, Uargs(s) = {}, Uargs(+) = {}, Uargs(sum^#) = {},
Uargs(c_1) = {}, Uargs(+^#) = {}, Uargs(c_2) = {}, Uargs(c_3) = {}
We have the following constructor-restricted matrix interpretation:
Interpretation Functions:
sum(x1) = [0] x1 + [0]
0() = [0]
s(x1) = [0] x1 + [0]
+(x1, x2) = [0] x1 + [0] x2 + [0]
sum^#(x1) = [0] x1 + [0]
c_0() = [0]
c_1(x1) = [0] x1 + [0]
+^#(x1, x2) = [0] x1 + [0] x2 + [0]
c_2(x1) = [0] x1 + [0]
c_3(x1) = [0] x1 + [0]
We apply the sub-processor on the resulting sub-problem:
'matrix-interpretation of dimension 1'
--------------------------------------
Answer: YES(?,O(1))
Input Problem: DP runtime-complexity with respect to
Strict Rules: {sum^#(0()) -> c_0()}
Weak Rules: {}
Proof Output:
The following argument positions are usable:
Uargs(sum^#) = {}
We have the following constructor-restricted matrix interpretation:
Interpretation Functions:
0() = [7]
sum^#(x1) = [1] x1 + [7]
c_0() = [1]
* Path {2}: inherited
-------------------
This path is subsumed by the proof of path {2}->{4}->{3}.
* Path {2}->{4}: inherited
------------------------
This path is subsumed by the proof of path {2}->{4}->{3}.
* Path {2}->{4}->{3}: MAYBE
-------------------------
The usable rules for this path are:
{ sum(0()) -> 0()
, sum(s(x)) -> +(sum(x), s(x))
, +(x, 0()) -> x
, +(x, s(y)) -> s(+(x, y))}
The weight gap principle does not apply:
The input cannot be shown compatible
Complexity induced by the adequate RMI: MAYBE
We apply the sub-processor on the resulting sub-problem:
'matrix-interpretation of dimension 1'
--------------------------------------
Answer: MAYBE
Input Problem: runtime-complexity with respect to
Rules:
{ +^#(x, s(y)) -> c_3(+^#(x, y))
, sum^#(s(x)) -> c_1(+^#(sum(x), s(x)))
, +^#(x, 0()) -> c_2(x)
, sum(0()) -> 0()
, sum(s(x)) -> +(sum(x), s(x))
, +(x, 0()) -> x
, +(x, s(y)) -> s(+(x, y))}
Proof Output:
The input cannot be shown compatible
4) 'matrix-interpretation of dimension 1' failed due to the following reason:
The input cannot be shown compatible
5) 'Bounds with perSymbol-enrichment and initial automaton 'match'' failed due to the following reason:
match-boundness of the problem could not be verified.
6) 'Bounds with minimal-enrichment and initial automaton 'match'' failed due to the following reason:
match-boundness of the problem could not be verified.
Tool pair1rc
Execution Time | Unknown |
---|
Answer | MAYBE |
---|
Input | SK90 2.18 |
---|
stdout:
MAYBE
We consider the following Problem:
Strict Trs:
{ sum(0()) -> 0()
, sum(s(x)) -> +(sum(x), s(x))
, +(x, 0()) -> x
, +(x, s(y)) -> s(+(x, y))}
StartTerms: basic terms
Strategy: none
Certificate: MAYBE
Application of 'pair1 (timeout of 60.0 seconds)':
-------------------------------------------------
The processor is not applicable, reason is:
Input problem is not restricted to innermost rewriting
We abort the transformation and continue with the subprocessor on the problem
Strict Trs:
{ sum(0()) -> 0()
, sum(s(x)) -> +(sum(x), s(x))
, +(x, 0()) -> x
, +(x, s(y)) -> s(+(x, y))}
StartTerms: basic terms
Strategy: none
1) None of the processors succeeded.
Details of failed attempt(s):
-----------------------------
1) 'dp' failed due to the following reason:
We have computed the following dependency pairs
Strict Dependency Pairs:
{ sum^#(0()) -> c_1()
, sum^#(s(x)) -> c_2(+^#(sum(x), s(x)))
, +^#(x, 0()) -> c_3(x)
, +^#(x, s(y)) -> c_4(+^#(x, y))}
We consider the following Problem:
Strict DPs:
{ sum^#(0()) -> c_1()
, sum^#(s(x)) -> c_2(+^#(sum(x), s(x)))
, +^#(x, 0()) -> c_3(x)
, +^#(x, s(y)) -> c_4(+^#(x, y))}
Strict Trs:
{ sum(0()) -> 0()
, sum(s(x)) -> +(sum(x), s(x))
, +(x, 0()) -> x
, +(x, s(y)) -> s(+(x, y))}
StartTerms: basic terms
Strategy: none
Certificate: MAYBE
Application of 'Fastest':
-------------------------
None of the processors succeeded.
Details of failed attempt(s):
-----------------------------
1) 'pathanalysis' failed due to the following reason:
We use following congruence DG for path analysis
->{1} [ ? ]
->{2} [ MAYBE ]
|
`->{4} [ ? ]
|
`->{3} [ ? ]
Here rules are as follows:
{ 1: sum^#(0()) -> c_1()
, 2: sum^#(s(x)) -> c_2(+^#(sum(x), s(x)))
, 3: +^#(x, 0()) -> c_3(x)
, 4: +^#(x, s(y)) -> c_4(+^#(x, y))}
* Path {1}: ?
-----------
CANNOT find proof of path {1}. Propably computation has been aborted since some other path cannot be solved.
* Path {2}: MAYBE
---------------
We consider the following Problem:
Strict DPs: {sum^#(s(x)) -> c_2(+^#(sum(x), s(x)))}
Strict Trs:
{ sum(0()) -> 0()
, sum(s(x)) -> +(sum(x), s(x))
, +(x, 0()) -> x
, +(x, s(y)) -> s(+(x, y))}
StartTerms: basic terms
Strategy: none
Certificate: MAYBE
Application of 'removetails >>> ... >>> ... >>> ...':
-----------------------------------------------------
The processor is inapplicable since the strict component of the
input problem is not empty
We abort the transformation and continue with the subprocessor on the problem
Strict DPs: {sum^#(s(x)) -> c_2(+^#(sum(x), s(x)))}
Strict Trs:
{ sum(0()) -> 0()
, sum(s(x)) -> +(sum(x), s(x))
, +(x, 0()) -> x
, +(x, s(y)) -> s(+(x, y))}
StartTerms: basic terms
Strategy: none
1) The weightgap principle applies, where following rules are oriented strictly:
Dependency Pairs: {sum^#(s(x)) -> c_2(+^#(sum(x), s(x)))}
Interpretation:
---------------
The following argument positions are usable:
Uargs(sum) = {}, Uargs(s) = {1}, Uargs(+) = {1}, Uargs(sum^#) = {},
Uargs(c_2) = {1}, Uargs(+^#) = {1}, Uargs(c_3) = {},
Uargs(c_4) = {}
We have the following constructor-restricted (at most 1 in the main diagonals) matrix interpretation:
Interpretation Functions:
sum(x1) = [0 0] x1 + [0]
[0 0] [0]
0() = [0]
[0]
s(x1) = [1 0] x1 + [0]
[0 0] [0]
+(x1, x2) = [2 0] x1 + [0 0] x2 + [0]
[0 0] [0 0] [0]
sum^#(x1) = [0 0] x1 + [3]
[0 0] [3]
c_1() = [0]
[0]
c_2(x1) = [1 0] x1 + [0]
[0 1] [0]
+^#(x1, x2) = [2 0] x1 + [0 0] x2 + [1]
[0 0] [0 0] [3]
c_3(x1) = [0 0] x1 + [0]
[0 0] [0]
c_4(x1) = [0 0] x1 + [0]
[0 0] [0]
The strictly oriented rules are moved into the weak component.
We consider the following Problem:
Strict Trs:
{ sum(0()) -> 0()
, sum(s(x)) -> +(sum(x), s(x))
, +(x, 0()) -> x
, +(x, s(y)) -> s(+(x, y))}
Weak DPs: {sum^#(s(x)) -> c_2(+^#(sum(x), s(x)))}
StartTerms: basic terms
Strategy: none
Certificate: MAYBE
Application of 'removetails >>> ... >>> ... >>> ...':
-----------------------------------------------------
The processor is inapplicable since the strict component of the
input problem is not empty
We abort the transformation and continue with the subprocessor on the problem
Strict Trs:
{ sum(0()) -> 0()
, sum(s(x)) -> +(sum(x), s(x))
, +(x, 0()) -> x
, +(x, s(y)) -> s(+(x, y))}
Weak DPs: {sum^#(s(x)) -> c_2(+^#(sum(x), s(x)))}
StartTerms: basic terms
Strategy: none
1) The weightgap principle applies, where following rules are oriented strictly:
TRS Component: {sum(0()) -> 0()}
Interpretation:
---------------
The following argument positions are usable:
Uargs(sum) = {}, Uargs(s) = {1}, Uargs(+) = {1},
Uargs(sum^#) = {}, Uargs(c_2) = {1}, Uargs(+^#) = {1},
Uargs(c_3) = {}, Uargs(c_4) = {}
We have the following constructor-restricted (at most 1 in the main diagonals) matrix interpretation:
Interpretation Functions:
sum(x1) = [2 0] x1 + [0]
[2 0] [0]
0() = [2]
[0]
s(x1) = [1 0] x1 + [0]
[0 0] [2]
+(x1, x2) = [1 0] x1 + [0 0] x2 + [0]
[0 0] [0 2] [0]
sum^#(x1) = [2 0] x1 + [3]
[0 0] [3]
c_1() = [0]
[0]
c_2(x1) = [1 0] x1 + [0]
[0 1] [0]
+^#(x1, x2) = [1 0] x1 + [0 0] x2 + [3]
[0 0] [0 0] [3]
c_3(x1) = [0 0] x1 + [0]
[0 0] [0]
c_4(x1) = [0 0] x1 + [0]
[0 0] [0]
The strictly oriented rules are moved into the weak component.
We consider the following Problem:
Strict Trs:
{ sum(s(x)) -> +(sum(x), s(x))
, +(x, 0()) -> x
, +(x, s(y)) -> s(+(x, y))}
Weak DPs: {sum^#(s(x)) -> c_2(+^#(sum(x), s(x)))}
Weak Trs: {sum(0()) -> 0()}
StartTerms: basic terms
Strategy: none
Certificate: MAYBE
Application of 'removetails >>> ... >>> ... >>> ...':
-----------------------------------------------------
The processor is inapplicable since the strict component of the
input problem is not empty
We abort the transformation and continue with the subprocessor on the problem
Strict Trs:
{ sum(s(x)) -> +(sum(x), s(x))
, +(x, 0()) -> x
, +(x, s(y)) -> s(+(x, y))}
Weak DPs: {sum^#(s(x)) -> c_2(+^#(sum(x), s(x)))}
Weak Trs: {sum(0()) -> 0()}
StartTerms: basic terms
Strategy: none
1) The weightgap principle applies, where following rules are oriented strictly:
TRS Component: {+(x, 0()) -> x}
Interpretation:
---------------
The following argument positions are usable:
Uargs(sum) = {}, Uargs(s) = {1}, Uargs(+) = {1},
Uargs(sum^#) = {}, Uargs(c_2) = {1}, Uargs(+^#) = {1},
Uargs(c_3) = {}, Uargs(c_4) = {}
We have the following constructor-restricted (at most 1 in the main diagonals) matrix interpretation:
Interpretation Functions:
sum(x1) = [0 0] x1 + [0]
[0 0] [0]
0() = [0]
[0]
s(x1) = [1 0] x1 + [0]
[0 0] [0]
+(x1, x2) = [2 0] x1 + [0 0] x2 + [2]
[0 2] [0 0] [0]
sum^#(x1) = [0 0] x1 + [3]
[0 0] [3]
c_1() = [0]
[0]
c_2(x1) = [1 0] x1 + [0]
[0 1] [0]
+^#(x1, x2) = [1 0] x1 + [0 0] x2 + [3]
[0 0] [0 0] [3]
c_3(x1) = [0 0] x1 + [0]
[0 0] [0]
c_4(x1) = [0 0] x1 + [0]
[0 0] [0]
The strictly oriented rules are moved into the weak component.
We consider the following Problem:
Strict Trs:
{ sum(s(x)) -> +(sum(x), s(x))
, +(x, s(y)) -> s(+(x, y))}
Weak DPs: {sum^#(s(x)) -> c_2(+^#(sum(x), s(x)))}
Weak Trs:
{ +(x, 0()) -> x
, sum(0()) -> 0()}
StartTerms: basic terms
Strategy: none
Certificate: MAYBE
Application of 'removetails >>> ... >>> ... >>> ...':
-----------------------------------------------------
The processor is inapplicable since the strict component of
the input problem is not empty
We abort the transformation and continue with the subprocessor on the problem
Strict Trs:
{ sum(s(x)) -> +(sum(x), s(x))
, +(x, s(y)) -> s(+(x, y))}
Weak DPs: {sum^#(s(x)) -> c_2(+^#(sum(x), s(x)))}
Weak Trs:
{ +(x, 0()) -> x
, sum(0()) -> 0()}
StartTerms: basic terms
Strategy: none
1) The weightgap principle applies, where following rules are oriented strictly:
TRS Component: {sum(s(x)) -> +(sum(x), s(x))}
Interpretation:
---------------
The following argument positions are usable:
Uargs(sum) = {}, Uargs(s) = {1}, Uargs(+) = {1},
Uargs(sum^#) = {}, Uargs(c_2) = {1},
Uargs(+^#) = {1}, Uargs(c_3) = {}, Uargs(c_4) = {}
We have the following constructor-restricted (at most 1 in the main diagonals) matrix interpretation:
Interpretation Functions:
sum(x1) = [2 0] x1 + [0]
[0 0] [0]
0() = [0]
[0]
s(x1) = [1 0] x1 + [2]
[0 0] [0]
+(x1, x2) = [1 0] x1 + [0 0] x2 + [0]
[0 2] [0 0] [0]
sum^#(x1) = [2 0] x1 + [3]
[0 0] [3]
c_1() = [0]
[0]
c_2(x1) = [1 0] x1 + [2]
[0 1] [2]
+^#(x1, x2) = [1 0] x1 + [0 0] x2 + [1]
[0 0] [0 0] [1]
c_3(x1) = [0 0] x1 + [0]
[0 0] [0]
c_4(x1) = [0 0] x1 + [0]
[0 0] [0]
The strictly oriented rules are moved into the weak component.
We consider the following Problem:
Strict Trs: {+(x, s(y)) -> s(+(x, y))}
Weak DPs: {sum^#(s(x)) -> c_2(+^#(sum(x), s(x)))}
Weak Trs:
{ sum(s(x)) -> +(sum(x), s(x))
, +(x, 0()) -> x
, sum(0()) -> 0()}
StartTerms: basic terms
Strategy: none
Certificate: MAYBE
Application of 'removetails >>> ... >>> ... >>> ...':
-----------------------------------------------------
The processor is inapplicable since the strict
component of the input problem is not empty
We apply the transformation 'weightgap of dimension Nat 2, maximal degree 1, cbits 4 <> ...' on the resulting sub-problems:
Sub-problem 1:
--------------
We consider the problem
Strict Trs: {+(x, s(y)) -> s(+(x, y))}
Weak DPs: {sum^#(s(x)) -> c_2(+^#(sum(x), s(x)))}
Weak Trs:
{ sum(s(x)) -> +(sum(x), s(x))
, +(x, 0()) -> x
, sum(0()) -> 0()}
StartTerms: basic terms
Strategy: none
We fail transforming the problem using 'weightgap of dimension Nat 2, maximal degree 1, cbits 4'
The weightgap principle does not apply
We try instead 'weightgap of dimension Nat 3, maximal degree 3, cbits 4 <> ...' on the problem
Strict Trs: {+(x, s(y)) -> s(+(x, y))}
Weak DPs: {sum^#(s(x)) -> c_2(+^#(sum(x), s(x)))}
Weak Trs:
{ sum(s(x)) -> +(sum(x), s(x))
, +(x, 0()) -> x
, sum(0()) -> 0()}
StartTerms: basic terms
Strategy: none
We fail transforming the problem using 'weightgap of dimension Nat 3, maximal degree 3, cbits 4'
The weightgap principle does not apply
We try instead 'weightgap of dimension Nat 4, maximal degree 3, cbits 4' on the problem
Strict Trs: {+(x, s(y)) -> s(+(x, y))}
Weak DPs: {sum^#(s(x)) -> c_2(+^#(sum(x), s(x)))}
Weak Trs:
{ sum(s(x)) -> +(sum(x), s(x))
, +(x, 0()) -> x
, sum(0()) -> 0()}
StartTerms: basic terms
Strategy: none
The weightgap principle does not apply
We abort the transformation and continue with the subprocessor on the problem
Strict Trs: {+(x, s(y)) -> s(+(x, y))}
Weak DPs: {sum^#(s(x)) -> c_2(+^#(sum(x), s(x)))}
Weak Trs:
{ sum(s(x)) -> +(sum(x), s(x))
, +(x, 0()) -> x
, sum(0()) -> 0()}
StartTerms: basic terms
Strategy: none
1) None of the processors succeeded.
Details of failed attempt(s):
-----------------------------
1) 'empty' failed due to the following reason:
Empty strict component of the problem is NOT empty.
2) 'Fastest' failed due to the following reason:
None of the processors succeeded.
Details of failed attempt(s):
-----------------------------
1) 'matrix-interpretation of dimension 4 (timeout of 100.0 seconds)' failed due to the following reason:
The input cannot be shown compatible
2) 'matrix-interpretation of dimension 3 (timeout of 100.0 seconds)' failed due to the following reason:
The input cannot be shown compatible
3) 'matrix-interpretation of dimension 2 (timeout of 100.0 seconds)' failed due to the following reason:
The input cannot be shown compatible
* Path {2}->{4}: ?
----------------
CANNOT find proof of path {2}->{4}. Propably computation has been aborted since some other path cannot be solved.
* Path {2}->{4}->{3}: ?
---------------------
CANNOT find proof of path {2}->{4}->{3}. Propably computation has been aborted since some other path cannot be solved.
2) 'Sequentially' failed due to the following reason:
None of the processors succeeded.
Details of failed attempt(s):
-----------------------------
1) 'empty' failed due to the following reason:
Empty strict component of the problem is NOT empty.
2) 'Fastest' failed due to the following reason:
None of the processors succeeded.
Details of failed attempt(s):
-----------------------------
1) 'matrix-interpretation of dimension 4 (timeout of 100.0 seconds)' failed due to the following reason:
The input cannot be shown compatible
2) 'matrix-interpretation of dimension 3 (timeout of 100.0 seconds)' failed due to the following reason:
The input cannot be shown compatible
3) 'matrix-interpretation of dimension 2 (timeout of 100.0 seconds)' failed due to the following reason:
The input cannot be shown compatible
2) 'Fastest' failed due to the following reason:
None of the processors succeeded.
Details of failed attempt(s):
-----------------------------
1) 'Sequentially' failed due to the following reason:
None of the processors succeeded.
Details of failed attempt(s):
-----------------------------
1) 'empty' failed due to the following reason:
Empty strict component of the problem is NOT empty.
2) 'Fastest' failed due to the following reason:
None of the processors succeeded.
Details of failed attempt(s):
-----------------------------
1) 'matrix-interpretation of dimension 4 (timeout of 100.0 seconds)' failed due to the following reason:
The input cannot be shown compatible
2) 'matrix-interpretation of dimension 3 (timeout of 100.0 seconds)' failed due to the following reason:
The input cannot be shown compatible
3) 'matrix-interpretation of dimension 2 (timeout of 100.0 seconds)' failed due to the following reason:
The input cannot be shown compatible
2) 'Fastest' failed due to the following reason:
None of the processors succeeded.
Details of failed attempt(s):
-----------------------------
1) 'Bounds with perSymbol-enrichment and initial automaton 'match'' failed due to the following reason:
match-boundness of the problem could not be verified.
2) 'Bounds with minimal-enrichment and initial automaton 'match'' failed due to the following reason:
match-boundness of the problem could not be verified.
Arrrr..Tool pair2rc
Execution Time | Unknown |
---|
Answer | MAYBE |
---|
Input | SK90 2.18 |
---|
stdout:
MAYBE
We consider the following Problem:
Strict Trs:
{ sum(0()) -> 0()
, sum(s(x)) -> +(sum(x), s(x))
, +(x, 0()) -> x
, +(x, s(y)) -> s(+(x, y))}
StartTerms: basic terms
Strategy: none
Certificate: MAYBE
Application of 'pair2 (timeout of 60.0 seconds)':
-------------------------------------------------
The processor is not applicable, reason is:
Input problem is not restricted to innermost rewriting
We abort the transformation and continue with the subprocessor on the problem
Strict Trs:
{ sum(0()) -> 0()
, sum(s(x)) -> +(sum(x), s(x))
, +(x, 0()) -> x
, +(x, s(y)) -> s(+(x, y))}
StartTerms: basic terms
Strategy: none
1) None of the processors succeeded.
Details of failed attempt(s):
-----------------------------
1) 'dp' failed due to the following reason:
We have computed the following dependency pairs
Strict Dependency Pairs:
{ sum^#(0()) -> c_1()
, sum^#(s(x)) -> c_2(+^#(sum(x), s(x)))
, +^#(x, 0()) -> c_3(x)
, +^#(x, s(y)) -> c_4(+^#(x, y))}
We consider the following Problem:
Strict DPs:
{ sum^#(0()) -> c_1()
, sum^#(s(x)) -> c_2(+^#(sum(x), s(x)))
, +^#(x, 0()) -> c_3(x)
, +^#(x, s(y)) -> c_4(+^#(x, y))}
Strict Trs:
{ sum(0()) -> 0()
, sum(s(x)) -> +(sum(x), s(x))
, +(x, 0()) -> x
, +(x, s(y)) -> s(+(x, y))}
StartTerms: basic terms
Strategy: none
Certificate: MAYBE
Application of 'Fastest':
-------------------------
None of the processors succeeded.
Details of failed attempt(s):
-----------------------------
1) 'pathanalysis' failed due to the following reason:
We use following congruence DG for path analysis
->{1} [ ? ]
->{2} [ MAYBE ]
|
`->{4} [ ? ]
|
`->{3} [ ? ]
Here rules are as follows:
{ 1: sum^#(0()) -> c_1()
, 2: sum^#(s(x)) -> c_2(+^#(sum(x), s(x)))
, 3: +^#(x, 0()) -> c_3(x)
, 4: +^#(x, s(y)) -> c_4(+^#(x, y))}
* Path {1}: ?
-----------
CANNOT find proof of path {1}. Propably computation has been aborted since some other path cannot be solved.
* Path {2}: MAYBE
---------------
We consider the following Problem:
Strict DPs: {sum^#(s(x)) -> c_2(+^#(sum(x), s(x)))}
Strict Trs:
{ sum(0()) -> 0()
, sum(s(x)) -> +(sum(x), s(x))
, +(x, 0()) -> x
, +(x, s(y)) -> s(+(x, y))}
StartTerms: basic terms
Strategy: none
Certificate: MAYBE
Application of 'removetails >>> ... >>> ... >>> ...':
-----------------------------------------------------
The processor is inapplicable since the strict component of the
input problem is not empty
We abort the transformation and continue with the subprocessor on the problem
Strict DPs: {sum^#(s(x)) -> c_2(+^#(sum(x), s(x)))}
Strict Trs:
{ sum(0()) -> 0()
, sum(s(x)) -> +(sum(x), s(x))
, +(x, 0()) -> x
, +(x, s(y)) -> s(+(x, y))}
StartTerms: basic terms
Strategy: none
1) The weightgap principle applies, where following rules are oriented strictly:
Dependency Pairs: {sum^#(s(x)) -> c_2(+^#(sum(x), s(x)))}
Interpretation:
---------------
The following argument positions are usable:
Uargs(sum) = {}, Uargs(s) = {1}, Uargs(+) = {1}, Uargs(sum^#) = {},
Uargs(c_2) = {1}, Uargs(+^#) = {1}, Uargs(c_3) = {},
Uargs(c_4) = {}
We have the following constructor-restricted (at most 1 in the main diagonals) matrix interpretation:
Interpretation Functions:
sum(x1) = [0 0] x1 + [0]
[0 0] [0]
0() = [0]
[0]
s(x1) = [1 0] x1 + [0]
[0 0] [0]
+(x1, x2) = [2 0] x1 + [0 0] x2 + [0]
[0 0] [0 0] [0]
sum^#(x1) = [0 0] x1 + [3]
[0 0] [3]
c_1() = [0]
[0]
c_2(x1) = [1 0] x1 + [0]
[0 1] [0]
+^#(x1, x2) = [2 0] x1 + [0 0] x2 + [1]
[0 0] [0 0] [3]
c_3(x1) = [0 0] x1 + [0]
[0 0] [0]
c_4(x1) = [0 0] x1 + [0]
[0 0] [0]
The strictly oriented rules are moved into the weak component.
We consider the following Problem:
Strict Trs:
{ sum(0()) -> 0()
, sum(s(x)) -> +(sum(x), s(x))
, +(x, 0()) -> x
, +(x, s(y)) -> s(+(x, y))}
Weak DPs: {sum^#(s(x)) -> c_2(+^#(sum(x), s(x)))}
StartTerms: basic terms
Strategy: none
Certificate: MAYBE
Application of 'removetails >>> ... >>> ... >>> ...':
-----------------------------------------------------
The processor is inapplicable since the strict component of the
input problem is not empty
We abort the transformation and continue with the subprocessor on the problem
Strict Trs:
{ sum(0()) -> 0()
, sum(s(x)) -> +(sum(x), s(x))
, +(x, 0()) -> x
, +(x, s(y)) -> s(+(x, y))}
Weak DPs: {sum^#(s(x)) -> c_2(+^#(sum(x), s(x)))}
StartTerms: basic terms
Strategy: none
1) The weightgap principle applies, where following rules are oriented strictly:
TRS Component: {sum(0()) -> 0()}
Interpretation:
---------------
The following argument positions are usable:
Uargs(sum) = {}, Uargs(s) = {1}, Uargs(+) = {1},
Uargs(sum^#) = {}, Uargs(c_2) = {1}, Uargs(+^#) = {1},
Uargs(c_3) = {}, Uargs(c_4) = {}
We have the following constructor-restricted (at most 1 in the main diagonals) matrix interpretation:
Interpretation Functions:
sum(x1) = [2 0] x1 + [0]
[2 0] [0]
0() = [2]
[0]
s(x1) = [1 0] x1 + [0]
[0 0] [2]
+(x1, x2) = [1 0] x1 + [0 0] x2 + [0]
[0 0] [0 2] [0]
sum^#(x1) = [2 0] x1 + [3]
[0 0] [3]
c_1() = [0]
[0]
c_2(x1) = [1 0] x1 + [0]
[0 1] [0]
+^#(x1, x2) = [1 0] x1 + [0 0] x2 + [3]
[0 0] [0 0] [3]
c_3(x1) = [0 0] x1 + [0]
[0 0] [0]
c_4(x1) = [0 0] x1 + [0]
[0 0] [0]
The strictly oriented rules are moved into the weak component.
We consider the following Problem:
Strict Trs:
{ sum(s(x)) -> +(sum(x), s(x))
, +(x, 0()) -> x
, +(x, s(y)) -> s(+(x, y))}
Weak DPs: {sum^#(s(x)) -> c_2(+^#(sum(x), s(x)))}
Weak Trs: {sum(0()) -> 0()}
StartTerms: basic terms
Strategy: none
Certificate: MAYBE
Application of 'removetails >>> ... >>> ... >>> ...':
-----------------------------------------------------
The processor is inapplicable since the strict component of the
input problem is not empty
We abort the transformation and continue with the subprocessor on the problem
Strict Trs:
{ sum(s(x)) -> +(sum(x), s(x))
, +(x, 0()) -> x
, +(x, s(y)) -> s(+(x, y))}
Weak DPs: {sum^#(s(x)) -> c_2(+^#(sum(x), s(x)))}
Weak Trs: {sum(0()) -> 0()}
StartTerms: basic terms
Strategy: none
1) The weightgap principle applies, where following rules are oriented strictly:
TRS Component: {+(x, 0()) -> x}
Interpretation:
---------------
The following argument positions are usable:
Uargs(sum) = {}, Uargs(s) = {1}, Uargs(+) = {1},
Uargs(sum^#) = {}, Uargs(c_2) = {1}, Uargs(+^#) = {1},
Uargs(c_3) = {}, Uargs(c_4) = {}
We have the following constructor-restricted (at most 1 in the main diagonals) matrix interpretation:
Interpretation Functions:
sum(x1) = [0 0] x1 + [0]
[0 0] [0]
0() = [0]
[0]
s(x1) = [1 0] x1 + [0]
[0 0] [0]
+(x1, x2) = [2 0] x1 + [0 0] x2 + [2]
[0 2] [0 0] [0]
sum^#(x1) = [0 0] x1 + [3]
[0 0] [3]
c_1() = [0]
[0]
c_2(x1) = [1 0] x1 + [0]
[0 1] [0]
+^#(x1, x2) = [1 0] x1 + [0 0] x2 + [3]
[0 0] [0 0] [3]
c_3(x1) = [0 0] x1 + [0]
[0 0] [0]
c_4(x1) = [0 0] x1 + [0]
[0 0] [0]
The strictly oriented rules are moved into the weak component.
We consider the following Problem:
Strict Trs:
{ sum(s(x)) -> +(sum(x), s(x))
, +(x, s(y)) -> s(+(x, y))}
Weak DPs: {sum^#(s(x)) -> c_2(+^#(sum(x), s(x)))}
Weak Trs:
{ +(x, 0()) -> x
, sum(0()) -> 0()}
StartTerms: basic terms
Strategy: none
Certificate: MAYBE
Application of 'removetails >>> ... >>> ... >>> ...':
-----------------------------------------------------
The processor is inapplicable since the strict component of
the input problem is not empty
We abort the transformation and continue with the subprocessor on the problem
Strict Trs:
{ sum(s(x)) -> +(sum(x), s(x))
, +(x, s(y)) -> s(+(x, y))}
Weak DPs: {sum^#(s(x)) -> c_2(+^#(sum(x), s(x)))}
Weak Trs:
{ +(x, 0()) -> x
, sum(0()) -> 0()}
StartTerms: basic terms
Strategy: none
1) The weightgap principle applies, where following rules are oriented strictly:
TRS Component: {sum(s(x)) -> +(sum(x), s(x))}
Interpretation:
---------------
The following argument positions are usable:
Uargs(sum) = {}, Uargs(s) = {1}, Uargs(+) = {1},
Uargs(sum^#) = {}, Uargs(c_2) = {1},
Uargs(+^#) = {1}, Uargs(c_3) = {}, Uargs(c_4) = {}
We have the following constructor-restricted (at most 1 in the main diagonals) matrix interpretation:
Interpretation Functions:
sum(x1) = [2 0] x1 + [0]
[0 0] [0]
0() = [0]
[0]
s(x1) = [1 0] x1 + [2]
[0 0] [0]
+(x1, x2) = [1 0] x1 + [0 0] x2 + [0]
[0 2] [0 0] [0]
sum^#(x1) = [2 0] x1 + [3]
[0 0] [3]
c_1() = [0]
[0]
c_2(x1) = [1 0] x1 + [2]
[0 1] [2]
+^#(x1, x2) = [1 0] x1 + [0 0] x2 + [1]
[0 0] [0 0] [1]
c_3(x1) = [0 0] x1 + [0]
[0 0] [0]
c_4(x1) = [0 0] x1 + [0]
[0 0] [0]
The strictly oriented rules are moved into the weak component.
We consider the following Problem:
Strict Trs: {+(x, s(y)) -> s(+(x, y))}
Weak DPs: {sum^#(s(x)) -> c_2(+^#(sum(x), s(x)))}
Weak Trs:
{ sum(s(x)) -> +(sum(x), s(x))
, +(x, 0()) -> x
, sum(0()) -> 0()}
StartTerms: basic terms
Strategy: none
Certificate: MAYBE
Application of 'removetails >>> ... >>> ... >>> ...':
-----------------------------------------------------
The processor is inapplicable since the strict
component of the input problem is not empty
We apply the transformation 'weightgap of dimension Nat 2, maximal degree 1, cbits 4 <> ...' on the resulting sub-problems:
Sub-problem 1:
--------------
We consider the problem
Strict Trs: {+(x, s(y)) -> s(+(x, y))}
Weak DPs: {sum^#(s(x)) -> c_2(+^#(sum(x), s(x)))}
Weak Trs:
{ sum(s(x)) -> +(sum(x), s(x))
, +(x, 0()) -> x
, sum(0()) -> 0()}
StartTerms: basic terms
Strategy: none
We fail transforming the problem using 'weightgap of dimension Nat 2, maximal degree 1, cbits 4'
The weightgap principle does not apply
We try instead 'weightgap of dimension Nat 3, maximal degree 3, cbits 4 <> ...' on the problem
Strict Trs: {+(x, s(y)) -> s(+(x, y))}
Weak DPs: {sum^#(s(x)) -> c_2(+^#(sum(x), s(x)))}
Weak Trs:
{ sum(s(x)) -> +(sum(x), s(x))
, +(x, 0()) -> x
, sum(0()) -> 0()}
StartTerms: basic terms
Strategy: none
We fail transforming the problem using 'weightgap of dimension Nat 3, maximal degree 3, cbits 4'
The weightgap principle does not apply
We try instead 'weightgap of dimension Nat 4, maximal degree 3, cbits 4' on the problem
Strict Trs: {+(x, s(y)) -> s(+(x, y))}
Weak DPs: {sum^#(s(x)) -> c_2(+^#(sum(x), s(x)))}
Weak Trs:
{ sum(s(x)) -> +(sum(x), s(x))
, +(x, 0()) -> x
, sum(0()) -> 0()}
StartTerms: basic terms
Strategy: none
The weightgap principle does not apply
We abort the transformation and continue with the subprocessor on the problem
Strict Trs: {+(x, s(y)) -> s(+(x, y))}
Weak DPs: {sum^#(s(x)) -> c_2(+^#(sum(x), s(x)))}
Weak Trs:
{ sum(s(x)) -> +(sum(x), s(x))
, +(x, 0()) -> x
, sum(0()) -> 0()}
StartTerms: basic terms
Strategy: none
1) None of the processors succeeded.
Details of failed attempt(s):
-----------------------------
1) 'Sequentially' failed due to the following reason:
None of the processors succeeded.
Details of failed attempt(s):
-----------------------------
1) 'empty' failed due to the following reason:
Empty strict component of the problem is NOT empty.
2) 'Fastest' failed due to the following reason:
None of the processors succeeded.
Details of failed attempt(s):
-----------------------------
1) 'matrix-interpretation of dimension 4 (timeout of 100.0 seconds)' failed due to the following reason:
The input cannot be shown compatible
2) 'matrix-interpretation of dimension 3 (timeout of 100.0 seconds)' failed due to the following reason:
The input cannot be shown compatible
3) 'matrix-interpretation of dimension 2 (timeout of 100.0 seconds)' failed due to the following reason:
The input cannot be shown compatible
2) 'compose (statically using 'split first congruence from CWD', multiplication)' failed due to the following reason:
Compose is inapplicable since some weak rule is size increasing
No subproblems were generated.
* Path {2}->{4}: ?
----------------
CANNOT find proof of path {2}->{4}. Propably computation has been aborted since some other path cannot be solved.
* Path {2}->{4}->{3}: ?
---------------------
CANNOT find proof of path {2}->{4}->{3}. Propably computation has been aborted since some other path cannot be solved.
2) 'Sequentially' failed due to the following reason:
None of the processors succeeded.
Details of failed attempt(s):
-----------------------------
1) 'empty' failed due to the following reason:
Empty strict component of the problem is NOT empty.
2) 'Fastest' failed due to the following reason:
None of the processors succeeded.
Details of failed attempt(s):
-----------------------------
1) 'matrix-interpretation of dimension 4 (timeout of 100.0 seconds)' failed due to the following reason:
The input cannot be shown compatible
2) 'matrix-interpretation of dimension 3 (timeout of 100.0 seconds)' failed due to the following reason:
The input cannot be shown compatible
3) 'matrix-interpretation of dimension 2 (timeout of 100.0 seconds)' failed due to the following reason:
The input cannot be shown compatible
2) 'Fastest' failed due to the following reason:
None of the processors succeeded.
Details of failed attempt(s):
-----------------------------
1) 'Sequentially' failed due to the following reason:
None of the processors succeeded.
Details of failed attempt(s):
-----------------------------
1) 'empty' failed due to the following reason:
Empty strict component of the problem is NOT empty.
2) 'Fastest' failed due to the following reason:
None of the processors succeeded.
Details of failed attempt(s):
-----------------------------
1) 'matrix-interpretation of dimension 4 (timeout of 100.0 seconds)' failed due to the following reason:
The input cannot be shown compatible
2) 'matrix-interpretation of dimension 3 (timeout of 100.0 seconds)' failed due to the following reason:
The input cannot be shown compatible
3) 'matrix-interpretation of dimension 2 (timeout of 100.0 seconds)' failed due to the following reason:
The input cannot be shown compatible
2) 'Fastest' failed due to the following reason:
None of the processors succeeded.
Details of failed attempt(s):
-----------------------------
1) 'Bounds with minimal-enrichment and initial automaton 'match'' failed due to the following reason:
match-boundness of the problem could not be verified.
2) 'Bounds with perSymbol-enrichment and initial automaton 'match'' failed due to the following reason:
match-boundness of the problem could not be verified.
Arrrr..Tool pair3irc
Execution Time | Unknown |
---|
Answer | TIMEOUT |
---|
Input | SK90 2.18 |
---|
stdout:
TIMEOUT
We consider the following Problem:
Strict Trs:
{ sum(0()) -> 0()
, sum(s(x)) -> +(sum(x), s(x))
, +(x, 0()) -> x
, +(x, s(y)) -> s(+(x, y))}
StartTerms: basic terms
Strategy: innermost
Certificate: TIMEOUT
Application of 'pair3 (timeout of 60.0 seconds)':
-------------------------------------------------
Computation stopped due to timeout after 60.0 seconds
Arrrr..Tool pair3rc
Execution Time | Unknown |
---|
Answer | TIMEOUT |
---|
Input | SK90 2.18 |
---|
stdout:
TIMEOUT
We consider the following Problem:
Strict Trs:
{ sum(0()) -> 0()
, sum(s(x)) -> +(sum(x), s(x))
, +(x, 0()) -> x
, +(x, s(y)) -> s(+(x, y))}
StartTerms: basic terms
Strategy: none
Certificate: TIMEOUT
Application of 'pair3 (timeout of 60.0 seconds)':
-------------------------------------------------
Computation stopped due to timeout after 60.0 seconds
Arrrr..Tool rc
Execution Time | Unknown |
---|
Answer | MAYBE |
---|
Input | SK90 2.18 |
---|
stdout:
MAYBE
We consider the following Problem:
Strict Trs:
{ sum(0()) -> 0()
, sum(s(x)) -> +(sum(x), s(x))
, +(x, 0()) -> x
, +(x, s(y)) -> s(+(x, y))}
StartTerms: basic terms
Strategy: none
Certificate: MAYBE
Application of 'rc (timeout of 60.0 seconds)':
----------------------------------------------
None of the processors succeeded.
Details of failed attempt(s):
-----------------------------
1) 'Fastest' failed due to the following reason:
None of the processors succeeded.
Details of failed attempt(s):
-----------------------------
1) 'Sequentially' failed due to the following reason:
None of the processors succeeded.
Details of failed attempt(s):
-----------------------------
1) 'empty' failed due to the following reason:
Empty strict component of the problem is NOT empty.
2) 'Fastest' failed due to the following reason:
None of the processors succeeded.
Details of failed attempt(s):
-----------------------------
1) 'matrix-interpretation of dimension 4 (timeout of 100.0 seconds)' failed due to the following reason:
The input cannot be shown compatible
2) 'matrix-interpretation of dimension 3 (timeout of 100.0 seconds)' failed due to the following reason:
The input cannot be shown compatible
3) 'matrix-interpretation of dimension 2 (timeout of 100.0 seconds)' failed due to the following reason:
The input cannot be shown compatible
2) 'Fastest' failed due to the following reason:
None of the processors succeeded.
Details of failed attempt(s):
-----------------------------
1) 'Bounds with minimal-enrichment and initial automaton 'match' (timeout of 100.0 seconds)' failed due to the following reason:
match-boundness of the problem could not be verified.
2) 'Bounds with perSymbol-enrichment and initial automaton 'match' (timeout of 5.0 seconds)' failed due to the following reason:
match-boundness of the problem could not be verified.
2) 'dp' failed due to the following reason:
We have computed the following dependency pairs
Strict Dependency Pairs:
{ sum^#(0()) -> c_1()
, sum^#(s(x)) -> c_2(+^#(sum(x), s(x)))
, +^#(x, 0()) -> c_3(x)
, +^#(x, s(y)) -> c_4(+^#(x, y))}
We consider the following Problem:
Strict DPs:
{ sum^#(0()) -> c_1()
, sum^#(s(x)) -> c_2(+^#(sum(x), s(x)))
, +^#(x, 0()) -> c_3(x)
, +^#(x, s(y)) -> c_4(+^#(x, y))}
Strict Trs:
{ sum(0()) -> 0()
, sum(s(x)) -> +(sum(x), s(x))
, +(x, 0()) -> x
, +(x, s(y)) -> s(+(x, y))}
StartTerms: basic terms
Strategy: none
Certificate: MAYBE
Application of 'usablerules':
-----------------------------
All rules are usable.
No subproblems were generated.
Arrrr..Tool tup3irc
Execution Time | 60.052174ms |
---|
Answer | TIMEOUT |
---|
Input | SK90 2.18 |
---|
stdout:
TIMEOUT
We consider the following Problem:
Strict Trs:
{ sum(0()) -> 0()
, sum(s(x)) -> +(sum(x), s(x))
, +(x, 0()) -> x
, +(x, s(y)) -> s(+(x, y))}
StartTerms: basic terms
Strategy: innermost
Certificate: TIMEOUT
Application of 'tup3 (timeout of 60.0 seconds)':
------------------------------------------------
Computation stopped due to timeout after 60.0 seconds
Arrrr..