ariel snir release 1amirben/projects/mcrf.pdf · proprietary and confidential information of ariel...

ARIEL SNIR RELEASE 1.0

Termination and Ranking Function Generation for Monotonicity Constraints Systems

Final Project

Error! Unknown

© Error! Unknown document property name.Error! Unknown document property name.2010 Ariel Snir

Document Information

Release: 1.0

Publication Date:

Catalog Number: MCRF V1.0

Information Security: Level 2 – Sensitive

Created: 1/5/2010

Account/FOP:

Author: Ariel Snir

Editor: Ariel Snir

Last Edited: 20/05/2010 9:19:18 AM

File Name: Termination and Ranking Function Generation for Monotonicity Constraints Systems.doc

Template: Product.dot

Error! Unknown

Proprietary and Confidential Information of Ariel Snir iii

Table of Contents

1 Introduction ........................................................................................................................... 1

Terms and Definitions .......................................................................................................................... 3

Preliminary knowledge ......................................................................................................................... 3 Well founded set ..................................................................................................................... 3

Monotonicity Constraints components ................................................................................... 4

Control-Flow Graph ................................................................................................................ 4

Multipaths ............................................................................................................................... 5

Threads .................................................................................................................................... 5

Size-Change Termination ....................................................................................................... 5

Monotonicity Constraints........................................................................................................ 5

State invariant ......................................................................................................................... 6

SCG versus MC ...................................................................................................................... 6

Monotonicity Constraint System ............................................................................................ 7

Parameters vs. variables .......................................................................................................... 7

Multipaths in MC Systems...................................................................................................... 7

Ranking Functions (global)..................................................................................................... 7

Importance of the Ranking Function .................................................................................................. 11 Certificate Termination ......................................................................................................... 11

Running time ......................................................................................................................... 11

Related Documents ........................................................................................................................... 11

2 Ranking Function Algorithm ............................................................................................. 13

Main Algorithm ................................................................................................................................... 13

Example walkthrough ......................................................................................................................... 14 Initial Status .......................................................................................................................... 14

Read input MCGs ................................................................................................................. 14

Removing inconsistent MCG ................................................................................................ 14

Elaboration ............................................................................................................................ 15

First call to calculate ranking function .................................................................................. 15

List the SCCs of A in reverse-topological order and form A’ (S1) ....................................... 15

Error! Unknown

Table of Contents

Proprietary and Confidential Information of Ariel Snir iv

MTP Calculation (S2) ........................................................................................................... 16

Remove MCGs with strict arc and hide in the other MCGs (S4) ................ 16

Append tuple to Ranking Function - For every f, let , . (S5) ........................... 17

Recursive call and return ρ · ρ if A’ is not vacant otherwise return ρ (S6) .......................... 17

List the SCCs of A in reverse-topological order and form A’ (S1) ....................................... 17

MTP Calculation (S2) ........................................................................................................... 19

Remove MCGs with strict arc and hide in the other MCGs (S4) ................ 19

Append tuple to Ranking Function - For every , let , . (S5) .......................... 20

Finish - A’ is vacant return ρ (S6) ........................................................................................ 20

MTP .................................................................................................................................................... 21 What is a MTP? .................................................................................................................... 21

MTP calculation .................................................................................................................... 21

Elaboration ......................................................................................................................................... 26 What is an elaboration? ......................................................................................................... 26

Deduce all the relations among all variables ........................................................................ 26

Example walkthrough ........................................................................................................... 27

General utilities .................................................................................................................................. 30

3 Data structure ..................................................................................................................... 32

UML description ................................................................................................................................. 32

Textual description ............................................................................................................................. 34 SCTACG ............................................................................................................................... 34

MCACG ................................................................................................................................ 34

SCG ....................................................................................................................................... 34

MCG ..................................................................................................................................... 34

Ranking Function .................................................................................................................. 35

Tuple ..................................................................................................................................... 35

RFPair ................................................................................................................................... 35

Fun ........................................................................................................................................ 35

Dep ........................................................................................................................................ 36

Var......................................................................................................................................... 36

Par ......................................................................................................................................... 36

MTP ...................................................................................................................................... 36

SCC ....................................................................................................................................... 36

ParType ................................................................................................................................. 36

Error! Unknown

Table of Contents

Proprietary and Confidential Information of Ariel Snir v

Rel ......................................................................................................................................... 36

Why did we use this Data Structure? ................................................................................................. 37

4 Complexity - Time & Space ............................................................................................... 38

5 Performance ........................................................................................................................ 39

6 Future enhancements ........................................................................................................ 42

7 Examples Book ................................................................................................................... 43 Basic Ackermann example - ack.csl ..................................................................................... 43

Program contains functions with varied parameters number ................................................ 43

Permuted variables ensure termination - FtoF_XdecYTagYDEQXTag.csl ......................... 43

On demand versus In advance – elaborationOnDemand.csl ................................................ 43

Fail to calculate RF of a non terminating example ............................................................... 43

Fail to calculate RF of a non terminating example with 3 MCGs ........................................ 44

MCG with negative cycle in input stage ............................................................................... 45

Prior elaboration step, the inconsistent will be removed. ..................................................... 46

MCG with negative cycle found in elaboration stage – ackInconsistentNegativeCycleInElaboration.csl .................................................................. 46

Program with two different functions - ackBack.csl ............................................................ 46

Functions with unique variable names - ackBackXYAB.csl ................................................ 47

8 Conclusion .......................................................................................................................... 51

9 References .......................................................................................................................... 52

Error! Unknown

Proprietary and Confidential Information of Ariel Snir 1

1 Introduction This project is based on research done by Amir Ben-Amram, Chin Soon Lee, Michael Codish and his colleagues and under the guidance of Amir Ben-Amram.

This project concerns with termination analysis, a fundamental problem in software verification. The halting (termination) problem is a decision problem which can be stated as follows: given a description of a program, decide whether the program finishes running or will run forever. Specifically, this project discusses a sub problem of termination analysis, which is the construction of a global ranking function.

Alan Turing proved in 1936 that a general algorithm to solve the halting problem for all possible program-input pairs cannot exist. We say that the halting problem is undecidable over Turing machines.

As the problem is undecidable in general, we make do with conservative (safe) approximations on a subset of programs. The termination problem arises in programs containing loops or recursive function calls that might not stop. The idea is to look for infinite loops/recursive calls which cause infinite descent over a well founded set of values. Because this is impossible, therefore termination is guaranteed.

For example:

Let the well founded set be for example ,

The following functional program:

add(x,y) =

if x=0 then y

else 1+add(x-1, y)

Example 1.1: add function.

1st parameter (x) decreases in every call.

Error! Unknown

Chapter 1. Introduction


Based on the impossibility of infinite descent, in every (hypothetical) chain of calls, something is shown to decrease indefinitely, which cannot really happen (because it’s taken from a well-founded order).

A sub problem of termination analysis is the construction of global ranking functions. Such a function is required to decrease in each step (transition - basic block or function call) of a program and the function witnesses the progress towards termination. An explicitly presented ranking function whose descent is (relatively) easy to verify is a useful certificate for termination [3] and may have other uses, such as for running-time analysis.

The method that we use for termination analysis will have two stages: 1. Abstraction of the program (the concrete program is replaced with an abstract one which is

independent of the programming language used by the original program). 2. Analysis of the abstract program

(The first stage is out of the scope of this project; however it will be briefly explained in some of the examples). The SCT method [4], views a program as a transitions system with states. The abstraction consists in forming a control-flow graph for the program, identifying a set of state variables, and forming a finite set of size change graphs that are abstractions of the program's transitions. In essence, a size-change graph is a set of inequalities between the variables of the source state and the target state. Thus, the SCT abstraction is an example of a transition system defined by constraints of a particular type. The technique concentrates on well-founded domains, where infinite descent is impossible. An SCT termination proof is a proof that any (hypothetical) infinite run would decrease some value monotonically and endlessly so that well-foundedness is contradicted. Since only chains of non-increasing values are of interest, only two types of inequalities were admitted into the size change graph of [4]:

1. - Old value of x greater than new value of y. 2. - Old value of x greater than or equal to new value of y.

Monotonicity Constraints [5] is a generalization of this method. Here, a transition may be described by any conjunction of order relations, including equalities as well as strict and non strict inequalities, and involving any pair of variables from the source state and target state. Thus, it can express:

1. The relations among source variables that applies to the states in which the transition may be taken.

2. The relations among the target variables, which applies to the states which the transition may produce.

3. As in SCT, relations involve a source variable and a target variable, but here equalities can be used, as well as relations like , that is, an increase.

It may happen that analysis of a program yields monotonicity constraints which are not size-change graphs. In such a case, simply approximating the constraints by a size-change graph may end up missing the termination proof. We will present Amir's algorithm to verify termination of a monotonicity constraint system while constructing a global ranking function, all in singly-exponential time, which is better than any other algorithm published so far.

Error! Unknown



Terms and Definitions ACG – Annotated Call Graph

APSP –All Pairs Shortest Paths

DS – Data Structure

Elaborated system – A system of MCGs that was elaborated from input MC system.

MC – Monotonicity Constraints

MCRF – Monotonicity Constraints Ranking Function

MCG – Monotonicity Constraints Graph

MTP – Maximal Thread Preserver

SCG – Size Changed Graph

Vacant – A CFG whose arc set is empty is called vacant

RF – Raking Function

SW – Software

Preliminary knowledge In this section we will scan briefly various terms and basic concepts required for understanding the issue we discuss.

Reminder: A partial order is a binary relation over a set P which is reflexive, antisymmetric, and transitive, i.e., for all a, b and c in P, we have that:

aRa (reflexivity); if aRb and bRa then a = b (antisymmetry); and If aRb and bRc then aRc (transitivity).

A set with a partial order is called a partially ordered set

Well founded set A well-founded set is a partially ordered set in which every non-empty subset has a minimal element.

A familiar example of a well-founded relation is the ordinary order relation on the set of natural numbers . Every non-empty subset of the natural numbers contains a smallest element.

Error! Unknown



Monotonicity Constraints components This diagram displays the various components used in MC theory. Use it as a reference for better understanding of the term used in this document.

Figure 1): Description of the various components in MC System.

Control-Flow Graph

A control-flow graph is a directed multigraph over the set of flow points of the program A. Control flow graph is a graphical representation of all paths that might be traversed during A’s execution. In such graph, node represents a function or a basic block and the edges represent a function call from function to where , . Possible function calls in a program:

Complex Add:

, ,

, 0 then , 1 1,

(This program returns the result value of ).

Example 1.2: Complex Add.

Figure 2): CFG for the program: Complex Add.

Error! Unknown



SCG – Size Change Graph Size-change graph is a set of constraints on source and target variables, where constraint can be either

(old value of x greater than new value of y) also known as strict arc, or (non strict arc).

Figure 3): SCG with two arcs.

Multipaths A multipath results of concatenating SCG’s along a CFG path. Example: a loop consisting of a single SCG. The single MCG:

Concatenation of the same MCG multiple times

Figure 4): Single SCG with permuted variables and Concatenation of the same MCG multiple times.

Threads A thread is a (infinite) path in the multipath. If there are infinitely many strict arcs, the thread is infinitely descending. In Figure 3 we can see two threads:

1. x y x y – start with x the first variable of function f then continue to y the second parameter of f and return back again to the start position - x the first variable of function f and continue.

2. Similarly, the thread y x y x .

Size-Change Termination Abstract Program is a control-flow graph where each arc (transition) is annotated with a size-change graph. An abstract program satisfies SCT if every infinite multipath contains an infinitely descending thread.

Monotonicity Constraints Monotonicity Constraints Graphs (MCGs) are a natural extension of size-change graphs. The extension consists of allowing any binary relation among >, ≥, = to be applied to any pair of variables in the two states. I.e. it is a conjunction of order constraints:

, , … , ,′, … , ′ , and , , .

Error! Unknown



Every CFG arc is associated with a monotonicity constraint . We write : .

State invariant For each , there is an invariant , which is a conjunction of order constraints among the variables.

SCG versus MC MC represented as a bipartite graph with nodes and edges. An MCG is associated with an arc in the CFG. Where each of the source function variables’ is associated with a node in the left side of the graph; And each of the destination function variables’ is associated with a node on the right side of the graph. If there is an order constraint from any variable to the other it will be denoted using an arc.

If the relation is strict decrease ( we will use red arc. If the relation is non strict – if it is we will use black arc, else if it is we will use blue arc.

Source Invariant is the relation constraints set on the source function variables. Destination Invariant is the relation constraints set on the destination function variables.

SC Graph MC Graph

- Relation from the source function variable

to destination function variable where is bigger

or equal than hence there is a non strict black arc

from to . - Relation from the source function variable

to destination function variable where source

function variable is bigger hence there is a strict red

arc from to . - Relation from the source function variable

to destination function variable where source

function variable is bigger hence there is a strict red

arc from to .

- Relation in the source invariant where is

bigger than hence there is a strict red arc from to .

- Relation in the destination invariant where

is bigger than hence there is a strict red arc from

to . - Relation from the destination function

variable to source function variable where is

bigger than hence there is a strict red arc from to .

- Relation from the source variable to

destination variable where they are equal hence

there is a non strict blue arc from to .

Figure 5): SCG vs. MCG.

Error! Unknown



Monotonicity Constraint System Definition 2.1 (MCS) [1]: A monotonicity constraint system, or MCS, is an abstract program representation that consists of a control-flow graph (CFG), monotonicity constraints and state invariants

Parameters vs. variables Every function has a list of variables. Variable is unique in a function element, variables of some function are the same among every appearance of this function in the system.

Every MCG has a list of source and destination parameters. Parameter is a unique in source/destination invariant of MCG. A parameter corresponds to unique variable. Every appearance of a function in the system as the source or destination of an MCG contributes a set of parameters to the MCG.

A source parameter corresponds to a variable of the MCG’s source function. I.e. in figure 1: p1 corresponds to v1 in MCG-0.

A destination parameter corresponds to a variable of the MCG’s destination function.

I.e. in figure 1: p7 corresponds to v1 in MCG-1.

Multipaths in MC Systems

Figure 6): Multipath in MC System.

Termination criterion in MC An MC system A is size-change terminating if every infinite A-multipath has an infinitely descending walk.

Ranking Functions (global)

Definition:

A state s consists of ordered state invariants associated with a point in the control flow graph. We will denote state as: , Let , be any predicate over states , , possibly written using variable names, e.g. 1 2

2 2. We write if , : , . Definition 2.10 [1] - A global ranking function for a transition system with state space St is a function : , where is a well-ordered set, that decreases on every transition. A ranking function for a MCS A is a ranking function for A. Namely, it satisfies for every A.

Error! Unknown



Every MCS has a RF of form:

var , … , var

if ...

.

.

.if

Where: The vectors v , … , v are tuples and the guards are order constraints.

1. Full version: tuples of variables and constants. Tuple of form:

< const , var , … , const , var

Note: On the last member there might be cases that the last pair of constant and variable there

will be only constant and it will be denoted by the dummy variable: “None”.

2. Short version: tuples of variables and constants. Tuple of form: <var , … , var

Shorter version when the variables name is known.

if ...

.

.

.if

Shorter version when the function name is known.

var ,… , var

if ...

.

.

.if

Example RF – Median RF

The following is an example for ranking function of the given MCS Α

MCG – 0 MCG – 1 MCG – 2

Figure 7): A given MCS

Error! Unknown



, ,, , , , , ,

This RF can be presented shortly as , , , , .

Verification of the RF Correctness Example:

MCG - 0 MCG – 1 MCG – 2

Figure 8): Assigning specific vector to the MCS A for verifying the RF correctness.

Note: The following RF example is written in the shorter version without the constants as part of the tuple inside the vector. It contains only the positions of the function variables.

, ,, , , , , ,

3,4,5, ,, ,, ,

4,4,5

0: 3,3,5, ,, ,, ,

3,3,5

1: 2,4,2, ,, ,, ,

2,4,2

2: 3,4,4, ,, ,, ,

4,4,4

Transition Does ?

3,4,5 3,3,5 4,4,5 3,3,5 Yes

3,4,5 2,4,2 4,4,5 2,4,2 Yes

3,4,5 3,4,4 4,4,5 4,4,4 Yes

Error! Unknown



Note: full verification should check all the various optional invariants (optional order constraints of variables in both source and target functions. We gave an example where the source invariant order constraint was: ).

The vector , , decreases on every transition as it should be in RF.

Error! Unknown



Importance of the Ranking Function

Certificate Termination The existence of a ranking function, for an MC system that corresponds to a program P, guarantees P’s termination.

The ranking function is used as a certificate, since ranking function for a transition system T with a state space St is a function : , where is a well-ordered set that decreases with every transition . As previously mentioned, an infinite descent over a well founded set of values is impossible. Hence, the program must terminate.

Unlike an algorithm, which only states whether a program terminates or not, our algorithm returns a ranking function whose reliability can be verified by assigning values to the variables in the various MCGs and validating that, for each state transition , .This makes our algorithm superior to other algorithms. Moreover, the ranking function infers the decreasing variables and the execution multi-paths that affect the program termination.

Running time Additional important contribution of ranking function is that it can imply the program's execution time bounds.

If the variables values are bounded integers, then we simply can calculate the execution time bound.

For example:

Let,

0, x , 0, y if 0, y , 1, None if 0, x , 2, y if

Where,

0 x, y , (n- is input parameter). Number of successive transitions n · n · | 0,1,2 | 3n

The execution time is bounded by 3n .

Related Documents 1. MC 1.0 User guide – describes the MC software functionalities.

2. Monotonicity Constraints - Javadoc – describes API and main classes.

Error! Unknown

Information Security Error! Unknown document property name. 13 Proprietary and Confidential Information of Ariel Snir

2 Ranking Function Algorithm This chapter describes the Main algorithm of calculating the RF. We will start by presenting the Algorithm and continue with an example walkthrough for better understanding of the algorithm.

Main Algorithm The algorithm for calculating the Ranking Function (ranking function construction for A - Algorithm 6.1 [2]) is as follows:

Let A be the elaborated System - It contains elaborated MCGs and elaborated ACG.

1. List the SCCs of A in reverse-topological order. For each , let κ be the position of the SCC of . Form Α by deleting all the intercomponent transitions. If A’ is vacant, return where , . If part of A’ is vacant (vacant = a CFG whose arc set is empty is called vacant), append to the ranking function for each function of the SCC.

2. For each SCC C, (C contains a group of functions that create a group of MCGs) compute the MTP, using the algorithm in [2]. If empty, report failure and exit.

3. For every , let be the lowest MTP variable of .

Error! Unknown

Chapter 2. Ranking Function Algorithm


4. For every graph : ,

if it includes (strict arc) then delete the graph from A’; else, retain the graph but hide x

5. For every f, let ρ f, σ κ , σ x .

6. If A’ is now vacant, return ρ.

Else, compute a ranking function ρ recursively for A’, and return ρ · ρ .

Example walkthrough This section walks through an example to see how the RF is being built step by step.

The example: ack.csl – abstract representation of the Ackermann function.

Reminder: Ackermann function:

,11,1

1, , 1

if 0if 0 0if 0 0

Initial Status No MCG was supplied as input.

Read input MCGs Read the input MCG from the input file.

Build the MC system object according to the input MCGs.

Figure 9): Abstraction of Ackermann function.

We can see both in the ACG B graph and in the MCGs graphs that there are two MCGs and both are .

Removing inconsistent MCG If there are inconsistent MCGs in the input they are removed prior to the elaboration stage.

Additionally, during elaboration if due to elaboration some elaborated MCG becomes inconsistent it will be removed from the elaborated MCGs system.

Error! Unknown



Elaboration

Figure 10): Full elaboration of Ackermann function.

First call to calculate ranking function Calling to calc Ranking function starts the RF calculation.

Note: We will label the next steps which describe the RF calculation with Sx where x is the step number in the RF calculation algorithm.

List the SCCs of A in reverse-topological order and form A’ (S1)

List the SCCs of A in reverse-topological order – we have a single SCC.

SCC 0 contains:

1. Functions: , , ,

2. 18 Elaborated MCGs all those above (described graphically).

For each , let κ be the position of the SCC of - which is 0.

Form A’ by deleting all the intercomponents transitions

In this case all the MCGs are in the SCC. No MCG connect between two SCCs. hence no MCG removed during the state - Form A’ by deleting all the intercomponents transitions

A’ is not vacant so we continue.

Error! Unknown



MTP Calculation (S2) MTP variables list of the single SCC:

, , , ,

For every f, let x be the lowest MTP variable of f (S3)

The variable of is since is not in the MTP.

The variable of is since both and are in the

MTP and . Hence, is the lowest MTP variable of ackx y (Optionally it could be also x since they are equal).

The variable of is since both and are in the

MTP and . Hence, is the lowest MTP variable of acky .

Remove MCGs with strict arc and hide in the other MCGs (S4)

Figure 11): Elaborated system after first removal of MCGs.

Each MCG with strict arc is deleted from A’.

Example of removed MCG

Figure 12): removed MCG - Elaborated MCG of MCG index: 1 .

There is a strict arc , hence it removed.

Example of retained MCG

Error! Unknown



Figure 13): Elaborated MCG of MCG index: 1 ack ack .

There is no strict arc in the MCG, hence it remains and we hide x – (hide is mark the variable x of function ack as hidden), this affects subsequent MTP computations, which will ignore the hidden variables.

Append tuple to Ranking Function - For every f, let , . (S5)

We have a single SCC. It has 3 functions: , , .

In the Append variable to Ranking function stage the algorithm does the following:

0 for each of the functions since all the functions in the only SCC and its index is 0.

x - is the lowest MTP variable of

σ x – Assignment of x .

ρ 0, .

ρ 0,

ρ 0,

Recursive call and return ρ · ρ if A’ is not vacant otherwise return ρ (S6) The RF after first append is:

0, x if 0, y if 0, x if

The system A’ is not vacant, hence we recursively call the function for calculating the Ranking Function (now handling the next tuple, with the residual system).

List the SCCs of A in reverse-topological order and form A’ (S1)

List the SCCs of A in reverse-topological order – we have 3 SCCs.

1. SCC 0 contains: Fun: ,Elaborated MCG of MCG index: 1

2. SCC 1 contains: Fun: , No elaborated MCG.

3. SCC 2 contains: Fun: ,Elaborated MCG of MCG index: 1

Error! Unknown



For each , let κ be the position of the SCC of .

Figure 14): SCC in topological order. And SCC in reversed topological order.

Form A’ by deleting all the intercomponents transitions

There are 3 intercomponents MCGs:

1. Elaborated MCG of MCG index: 1



Those 3 MCG connect between the SCCs. hence those 3 removed during the state -

Figure 15): Elaborated system after second removal of MCGs.

If A’ is not vacant so we continue. Else, If part of A’ is vacant (vacant = a CFG whose arc set is empty is called vacant), append to the ranking function for each function of the SCC.

As we saw SCC 1 contains: Fun: , No elaborated MCG The SCC 1 is vacant.

1 – The reversed topological order of the SCC is 1.

Hence 1,

Error! Unknown



We append the tuple: 1, and the current RF is:

,0, x if 0, y , 1, None if 0, x if

(And we remove this SCC from the SCC list).

MTP Calculation (S2)

SCC index (reversed topological order)

MTP variables

0

2

For every f, let x be the lowest MTP variable of f (S3)

The variable of is since is the only variable of in

the MTP.

The variable of is since is the only variable of in

the MTP.

Remove MCGs with strict arc and hide in the other MCGs (S4)

Figure 16): Elaborated system after third removal of MCGs.

Each MCG with strict arc is deleted from A’.

Example of removed MCG

Figure 17): Elaborated MCG of MCG index: 1 .

Example of retained MCG

Error! Unknown



Both last two MCGs removed in this case, there are no remaining MCGs.

Append tuple to Ranking Function - For every , let , . (S5)

We have a two SCC. Each has one function: and

SCC index (reversed topological order)

Function

0 κ 0

2 κ 2

Hence,

ρ 0,

ρ 2,

The RF after append is:

,0, , 0, 0, , 1, 0, , 2,

Finish - A’ is vacant return ρ (S6) The system A’ is vacant; hence we return the result Ranking Function.

Error! Unknown



MTP

What is a MTP?

Thread preserver (Definition 3.9 from [2] rephrased):

Let H be a set of size-change graphs. A set of variables VARS All_ _ is called a

Thread preserver for H if for every size-change graph: G H where G f g, it holds that whenever x _ f , there is x y G for some y .

MTP

The largest set which is a thread preserver. The MTP is required for the RF calculation.

MTP calculation The main function of the MTP calculation is compute(). Bellow we describe in details the MTP calculation which will be followed by an example.

Algorithm (Compute MTP):

Note: Every variable will be in one of the following states , ,

- The variable is not in the MTP.

- The variable is potentially still in the MTP.

- The variable is about to be removed from the MTP.

1. Preparations: Create a list of potential MTP variables in the SCC. Initially, all the variables which are not hidden are in the strongly connected component.

2. setup:

Initialize all variables to be .

Calculate the out degree of each source variable.

Prepare a list of the source parameters that enters to a destination variable for each destination variable.

The status of variable, that one of its parameters’ out-degree is 0, changes to .

3. Remove Variables:

Find all the variables that one of its parameters’ out-degree is 0 (the variables).

For each such variable

i. Call the function removeMTPVariable( ):

Remove from the potential MTP variables – change its status to .

Remove its effect on the out degree of other source parameters that used to enter this variable.

Error! Unknown



If the out-degree of some variable changes to 0, Remove the variable effect recursively.

4. Return the list of variables that weren't removed from the potential MTP variables.

Example

This example follows the steps of the MTP calculation.

In this example we have 2 MCGs:

1. MCG-0 - from function f1 to f2.

2. MCG-1- from function f2 to f1.

It is a strongly connected component.

Initial state

The out degree of the MCGs’ parameters is not calculated yet.

ACG:

MCGs:

Figure 18): MTP calculation example – initial stage

Setup MTP

The out degree of every parameter in each MCG is calculated.

The out degree (mtpCount) of the parameter in MCG-0 is 0 after MTP count calculation, hence the variable is MARKED.

Error! Unknown



Figure 19): MTP calculation example – after setup MTP stage.

Remove MTP Variables

Traverse the variables. If the variable is marked remove it.

Remove since it is MARKED after MTP count calculation. By call to RemoveMTPVariable().

Removal mark as ABSENT and remove the mtpCount of the parameters that enters into .

The mtpCount in MCG-1 remove from 2 to 1

The mtpCount in MCG-1 reduce from 1 to 0

Since mtpCount of in MCG-1 is 0 after removal, we recursively call to RemoveMTPVariable on .

Figure 20): MTP calculation example – after first removal of y f .

After recursive call to RemoveMTPVariable on :

Remove since it is MARKED after prior removal.

Removal mark as ABSENT and reduce the mtpCount of the parameters that enters into .

The mtpCount in MCG-1 reduce from 2 to 1

Since mtpCount of none of the parameters changed to 0, no recursive call is done.

Figure 21): MTP calculation example – after first removal of y f

Populate MTP Variables

Scanning the variables of the MCGs results with and as the MTP variables, since their status is still PRESENT (in any of the MCGs its parameters mtpCount didn’t reach to 0).

Detailed implementation description

List<Var> sct.MTP.compute()

Compute the MTP of a given List of variables of a given monotonicity constraint system. (I.e. the SCGs variables of the SCC). The variables were extracted from the SCGs and supplied in the initialization.

Error! Unknown



Returns: List the list of variables which are the MTP elements.

The main steps in the MTP calculation: 1. setupMTP(vars) 2. mtpRemoveVars(vars) 3. populateMTPVars()

setupMTP(List<Var> vars)

Setup required data for the MTP calculation.

Calculate the mtpCount (count the out degree) of every source parameters of every SCG in the SCC.

Calculate the pre-image MTP parameters of each variable: o For each destination variable,

Make a list of the parameters that enters the variable. (During MTP calculation in the variable's removal step we reduce the MTP count of each source parameter that used as source parameter that entered the destination variable.)

If the MTP of some par is 0 after the MTP count calculation, the MTP status of its variable changes from PRESENT to MARKED.

removeMTPVariables (vars)

PRE: For each var v in the current SCG element in SCC,

o v‐>mtpPreImagePars is set to those SCG nodes (pars) whose count is affected by

removal of v.

For each par x in the SCC,

o x‐>mtpCount is set to x's out‐degree.

o If x‐>mtpCount==0,

then the MTPStat field for the corresponding var is MARKED.

o Else, MTPStat is PRESENT.

POST: {v | v->mtpStat==PRESENT} is the MTP.

Remove the variables that were marked (A variable is MARKED if the MTP count of one of its source parameters is 0 after mtpCount calculation). For each variable that was marked, call to removeMTPVariable(). Removal of variable can result with removal of additional variables if their mtpCount becomes 0 during the recursive variable removal.

Parameters: vars the variable list of the SCC that its MTP is currently being calculated.

Error! Unknown



removeMTPVariable(Var var)

Remove affect of variable on the MTP calculation.

Remove variable by setting it MTP status to ABSENT. Remove its affect on the source parameters that used to enter this variable

(reduce the source parameter's mtpCount [hold the out degree] by 1). Recursively remove variable that its MTP count became 0 after removing the affect of the

variable. Algorithm:

mark var as absent for each source parameter 'x' that is affected by the var that we remove

o x.mtpCount-- o If x.mtpCount == 0

remove mtp var recursively of x's variable.

populateMTPVariables()

Scan the SCC variables and populate all the variables which are members of the MTP (PRESENT variables) to the MTP variables list

Returns: The MTP variables list

Error! Unknown



Elaboration

What is an elaboration? The elaboration process is a step where we create a new elaborated MC system A by traversing each MCG from the original input MC system B and generate all the possible permutations of relations among the source and destination variables of the MCG and create a new consistent elaborated MCG for each such permutation.

Definition:

Definition 5.4 [1] (full elaboration) – An MCS A is fully elaborated if the following conditions hold:

(1) Each state invariant fully specifies the relations among all variables.

That is, for i, j n, one of x x , x x or x x is implied by I .

(2) Each size-change graph G is closed under logical consequence.

(3) No MC in A is unsatisfiable.

Since the state invariant fully determines the relations among all variables,

We can re-index the variables into sorted order, so that the invariant becomes:

x x . . . x

Deduce all the relations among all variables The elaboration requires inference of all the relations between the MCG variables. In order to calculate the all the logical consequences, we use the Floyd Warshall algorithm for finding all shortest paths from each variable v to variable u where u, v V. Furthermore we use this algorithm to look for constraints inconsistencies - in case inconsistencies exist, an exception will be thrown to indicate for this error (negative cycle exception). Using the algorithm in our implementation requires some adjustments.

All path and its matrix values implementation in MC

The deviations from the standard APSP Algorithm are:

1. Change the weights values.

a. Thumb rules for relations composition and choosing the weight values:

i. NONE arc with any other arc should result with NONE.

ii. DEC arc with DEC or DEQ/EQ should result with DEC.

iii. EQ arc doesn’t affect the other arc it composed with hence it results with the relation type of the other arc.

b. Reminder: in the original All Paths algorithm every arc had weight. When there is no

relation from uv, value is set to infinity.

Error! Unknown



c. The values in the matrix:

relation Literal Value None NONE 2 > DEC 1 = EQ/DEQ 0

2. Change the operation on the composed arc. Instead of using ( ) operation use (max , , since that the mathematical operation holds for the thumb rules is with the

above weights is: max (a,b).

3. The condition if cheaper – The weight order (which relation’s value is cheaper) is as follow:

a. {DEC < EQ/DEQ < NONE} Note: EQ arc is translated to two DEQ arcs from and .

Update the graph by adding deduced arcs: If the cost after all paths calculation modified and its value is lower (cost is cheaper) than prior calculation we should update the relation to be tighter – with the better relation.

Example walkthrough We will walkthrough an example to see how the Elaboration done step by step.

We will see the difference between the two elaboration methods: on demand and in advance, using the example: elaborationOnDemand.csl

Elaboration On demand versus In Advance

Elaboration In advance

The elaboration process is a step where we create a new elaborated MC system A by traversing each MCG from the original input MC system B and generate all the possible permutations of relations among the source and destination invariants of the MCG and create a new consistent elaborated MCG for each such permutation, we don’t start from a root MCG or function, and we elaborate all the input MCGs also if they are unreachable by the first MCGs (Since they are inconsistent with the destination invariant and function constraints of previously elaborated MCG.

Elaboration On demand

In elaboration on demand we start from the first input MCG, elaborate it (only consistent MCGs left in the elaborated system), then we continue to elaborate from each such elaborated MCG we check if any of the other input MCGs is reachable and consistent with the destination invariant of the previously elaborated MCGs, if so we recursively elaborate the input MCG.

Error! Unknown



Example walkthrough

Initial status

In this example we see that we have as input 3 MCGs.

Figure 22): Elaboration on demand example - initial status

Step 1 – adding the root elaborated MCG

The root MCG will be the first MCG (MCG index #0). This input MCG will be elaborated. Since all the constraints on both source and destination invariant exists, only a single MCG ( f f MCG index: 0) will be elaborated from this input MCG.

Figure 23): Elaboration on demand example - After adding neighbor: f f MCG index: 0

Step 2 – adding the first elaborated MCG neighbor

The algorithm will look for the next MCG to be elaborated that is reachable and consistent with the root elaborated MCG f f MCG index: 0, it will find MCG index #1 and MCG index #2 (from the input MCGs). Hence, elaboration will be performed first on the first founded input MCG (MCG index #1) while keeping the relations constraints from the destination constraints of the elaborated MCG ff MCG index: 0. It will result with adding new elaborated MCG: f f MCG index: 1.


Error! Unknown



Step 3 – adding the second elaborated MCG neighbor

The algorithm will look for the next MCG to be elaborated that is reachable and consistent with the new elaborated MCG: f f MCG index: 1, it will find MCG index #1 and MCG index #2. MCG index #1 already elaborated with the invariant x=y, Hence, elaboration will be performed first on the next founded input MCG (MCG index #2) while keeping the relations constraints from the destination constraints of the elaborated MCG f f MCG index: 1. It will result with adding new elaborated MCG: f f MCG index: 2.


Step 4 – adding the third elaborated MCG neighbor

The algorithm will look for the next MCG to be elaborated that is reachable and consistent with the new elaborated MCG: f f MCG index: 2, it will find MCG index #0 and MCG index #1. MCG index #0 already elaborated with the source invariant x>y, Hence, elaboration will be performed first on the next founded input MCG (MCG index #1) while keeping the relations constraints from the destination constraints of the elaborated MCG f f MCG index: 1. It will result with adding new elaborated MCG: f f MCG index: 1.


This example presented the principle of rooted termination. You can see that elaboration was done on demand. Elaboration in advance on this example results with additional redundant unreachable node and arc: function - f and additional MCG - f f

Error! Unknown



Figure 27): Elaboration in advance example

Elaboration on demand is more accurate and can result with less elaboration effort that can improve performance. Moreover, it will not fail to calculate MTP due to unreachable code (for example if we add some unreachable MCG to the MC system in a separate SCC that will cause for inexistence of MTP).

General utilities SCC (Strongly connected component) Sharir - Kosaraju's algorithm is an algorithm for finding strongly connected components.

Get Adjacency List of nodes and root node where we start the search from. In case the graph contains more than connected component all the SCCs can achieved by going all the roots of the forest. The input: A graph and the root node. The output: SCC list. Every SCC contains a list of nodes. The SCCs list is a graph

Kosaraju-Sharir's Algorithm:

1. call DFS(G) to compute finishing times f(u) for each vertex u 2. compute G-Transpose 3. call DFS(G-Transpose), but in the main loop of DFS, consider the vertices in order of decreasing

f(u) (as computed in line 1) 4. Output the vertices of each tree in the depth-first forest formed in line 3 as a separate strongly

connected component.

Format Converters

In our area there are some well known conventions of monotonicity constraints syntax.

The known file formats are:

1. Chin Soon Lee and Amir Ben Amram. (CSL).

a. For SCT - \examples\examplesBook\ackCSLForSCT.csl

Error! Unknown



#Ackermann Function in CSL format for SCT #Our basic example { (ack ack {(x x dec)}), (ack ack {(x x deq) (y y dec)}) }

b. For MC System - \examples\examplesBook\ack.csl

#Ackermann Function in CSL format for MC system #Our basic example { (ack ack {(x x' dec)}), (ack ack {(x x' deq) (y y' dec)}) }

Note: target variable is marked by adding the tag character (') as its suffix.

2. Mike’s Codish (MC) - \examples\examplesBook\ackMikeCodish.mc

#Ackermann Function in Mike Codish format #Our basic example ack(x1, x2) :- [x1>y1] ; ack(y1, y2). ack(x1, x2) :- [x1>=y1, x2>y2] ; ack(y1, y2).

Note: Each of the examples above describes the same abstract system for the Ackermann function.

We supply two converters as part of the MC Software:

1. MC to CSL - Convert file from Mike’s Codish format to Chin Soon Lee and Amir Ben Amram format.

2. SC to MC - Convert from Size change Graphs to MC Graphs – Add tags to destination parameters in order to allow dependencies inside invariants.

Error! Unknown

Chapter 3. Data structure


3 Data structure This section describes the data structure used for implementation

UML description This UML diagram below describes the data structure used for implementation. This class diagram contains the main classes of the data structure and their relations.

Error! Unknown



Figure 28): Class Diagram of Monotonicity Constraints software implementation.

Error! Unknown



Textual description The Main Classes: This section contains description of the main java classes including some of the more interesting fields. The full description of the classes can be found in the Javadoc document for the project.

SCTACG Call Graph Annotated with SCG components.

This structure holds the SCGs supplied as the input system.

functionsMap – set of input functions indexed by functions unique name. A function denotes a node in the CFG.

scgs – list of the input SCGs.

MCACG Call Graph Annotated with MCG components.

This class inherits from SCTACG and extends it by adding required fields and function required for representing MC call graph.

This Class holds the MCGs that were supplied as the input abstract system that represent a language independent system.

rankingFunction - Ranking function object will hold the result Ranking function.

elaboratedFunList - Hold the set of elaborated functions objects in an ordered list.

SCG This class represents size change graph object. It has source and destination functions, source and destination parameters and a map of dependencies denotes the dependencies between the SCG parameters.

SCG has:

dependencyMap – A map of dependencies describing the relation constraints between source and destination variables.

It has a source and destination function.

sourceParamsMap - Map of source function parameters

destinationParamsMap - Map of destination function parameters

MCG Represents Monotonicity Constraint Graph object and inherits from SCG. MCG has source and destination invariants. Each invariant represents the constraints set among the respective set of parameters. Each invariant represented by a set of relations order.

sourceConstraintsMap - Set of dependencies in the source invariant indexed by a string representation of the constraint.

Error! Unknown



destinationConstraintsMap - Set of dependencies in the destination invariant indexed by a string representation of the constraint.

elaboratedMCGsNames – Set that holds the unique names of the elaborated MCGs.

elaboratedMCGs – Set of the elaborated MCGs created from this MCG. The list is ordered by order of creation. – exist only in original MCGs.

name - The unique name of the elaborated MCG describes the MCG. The unique name describes its source and destination invariants and original MCG.

Example:

o MCG name: Elaborated MCG: ack_x>y ack_x=y MCG index: 0.

o The name interpretation: Input MCG is the first MCG (index 0). The MCG source function is and its source constraints set is x The MCG destination function is and its destination constraints set is x y

Ranking Function This class represents the result ranking function object.

Contains an array of tuples of size: where

is the number of elaborated functions

Tuple A tuple is an array of RFPair of size where

is the number of variables in the elaborated function.

RFPair Hold a pair consisting of Constant and variable. The constant ( ) is the index of the SCC in the reversed topological order in a certain state in the algorithm. The variable (x ) is the lowest MTP variable of in the stage it is appended. In case of vacant SCC the variable position can be empty and we will have only the constant in the tuple.

Fun Fun represents function of a program. Each function has a variables list.

elaboratedFunctionsMap – set of elaborated functions corresponding to this function indexed by unique function name describing the elaborated function.

varsList – the function’s variables list

relations – represents the state invariant as a vector that contains function variable index in the even position and relation value in the odd position. Relation values can be {0 - for DEC, 1 - for EQ} i.e. the vector: [0 0 1], means: The variable in the index 0 of the function is bigger than the variable in the index 1

Error! Unknown



Dep Dep represents a relation constraint between two parameters.

In case of SCG dependency, describe a relation between source and destination parameters.

In case of MCG dependency, it represents a relation between any two source or destination parameters, where the relation can be , , and relation between source and destination variable.

Var Var is a unique variable in a function element.

mtpPreImagePars - Parameters affected by the variable in the MTP algorithm (see section 2).

sourceParameters – The list of source parameters from the various MCGs that correspond to Var.

Par Par is a unique parameter in source/destination invariant of MCG. A parameter corresponds to unique variable. Every appearance of a function in the system as the source or destination of an MCG contributes a set of parameters to the MCG. Par is an SCG node.

MTP This class represents MTP of a set of graphs H and implements the algorithm.

vars – hold the list of variables in the MTP

scgs - hold the list of scgs that we calculates its MTP

SCC This class represents a strongly connected component object. It holds the SCGs which represent the edges of the SCC It holds the functions which represents the nodes of the SCC.

ParType ParType is enumerator type including the optional parameter types – source or destination.

Rel Rel is an enumerator type including the relations that can be between two parameters. Denote an SCG’s or MCG’s arc.

Error! Unknown



Why did we use this Data Structure? The data structure is built using a combination of various basic data structure, designed to improve the ability to trace the status of the data structure along the various stages of the algorithm while preserving the theoretical complexity.

The thumb rules for selecting the appropriate data structures:

It uses HashMap / HashSet for fetch/get object or check if object exists – in approximately O 1 time.

It uses List to keep order of elements. Using ordered structures, aids in tracing the various stages of the algorithm upon various executions of the same input MCGs; and ensures deterministic results unlike randomized hash-sets. Data elements such as variables, elaborated functions and elaborated MCGs are held in lists. On behalf of performance, lists are used only when the algorithm requires traversal of the whole list in order to avoid redundant traverse of lists when a random access is required and feasible.

It uses ArrayList when both the need to preserve order and the ability to reach element in a known index in O 1 time is required.

It uses basic arrays when the number of elements is known in order to save on redundant reallocations.

Error! Unknown

Chapter 4. Complexity - Time & Space


4 Complexity - Time & Space The number of possible orderings of n variables plays a role in the combinatorics of fully elaborated instances. Note that also equalities are possible. Therefore, the number of orderings is not n! , But a slightly larger number called the n h ordered Bell number B . A known upper bound is B 2n (consider two cases—no equalities, or at least one). The first Bell numbers are B 1, B 3, B 13, 75, 541, 4683, 47293,….. The following theorem and lemma summarize the algorithm complexity: Theorem 6.17[1] (complexity of constructing rephrased: Let B be a terminating MCS, with m flow-points and n variables per point. There is a ranking function for B where , is defined by a set of ranking function vectors, each one associated with certain inequalities on variables, which define the region where the given vector is the function value. There are at most B different vectors for any flow-point. The complexity of constructing isO |B| · n . |B| - is the number of abstract transitions (MCs) in the MCS B. Lemma 5.8[1]: Any MCS B with n variables at any point can be transformed into a fully-elaborated system A, deterministically bisimulating B, in O |B| · n time and space. The elaborated system representation uses the most significant space in the memory. Hence, time and space complexity is singly exponential. This complexity is an improvement upon previous researches. Additional information regards the algorithm complexity can be found in [1 section 6.3]

Error! Unknown

Chapter 5. Performance


5 Performance Performance - Execution time and space analysis.

The theoretical complexity is singly exponential. In empirical performance tests, we examined the exponential effect of the parameters number on memory and execution time.

The following tables summarize execution of various examples and compare between execution time and memory usage of various MC Systems. These tables present the effect of parameters number to the number of MCGs on performance and memory usage.

Parameters MCGs

1 2 3 4 5

1 8 16 94 830 Few minutes. (failure due to Out of Memory)

2 8 16 101 1762 Out of memory

3 8 16 112 3120 Out of memory

4 9 16 117 4391 Out of memory

5 9 16 133 6170 Out of memory

Note: values describe the CPU time usage in millisecond (ms).

Number of MCGs affects execution time linearly

0

1000

2000

3000

4000

5000

6000

7000

1 2 3 4 5

1 parameter

2 parameters

3 parameters

4 parameters

linear 4 parameters

Error! Unknown



Parameters MCGs

1 2 3 4 5

1 4558 4852 5441 35882 Few minutes. (failure due to Out of Memory)

2 4705 5000 5882 72727 Out of memory

3 5000 5151 6363 107359 Out of memory

4 5147 5294 7424 143270 Out of memory

5 5294 5441 7500 177916 Out of memory

Note: values describe the heap memory usage in Kilobytes (KB).

Number of MCGs affects memory usage linearly

Examples can be found: inside the folder: examplesBook\performanceExamples\ of the MC SW.

Tables Summary:

Number of parameters affects execution time and memory usage exponentially. Number of MCGs affects execution time and memory usage linearly (can be seen in the example of 4 parameters). The effect is a bit more than linear due to overhead results from memory growth that increase execution time. I tried to check the origin for the deviations from theoretical linear growth; I think it results from memory management issues that increase the execution time a bit beyond expected. I checked the amount of calls to the GC and the duration of its work. I have noticed that GC work was enhanced when memory usage grows and I assume that it is probably the origin for the deviation.

0

20000

40000

60000

80000

100000

120000

140000

160000

180000

200000

1 2 3 4 5

hea

p m

emory usage in Kilo

bytes (KB)

Number of MCGs

1 parameter

2 parameters

3 parameters

4 parameters

linear 4 parameters

Error! Unknown



In case of small number of parameters (1-3) execution time and memory doesn’t grow significantly in the number of parameters due to additional overhead of the java environment respective to the minor execution time and memory usage of the actual algorithm.

Finally, multiple parameters result with slow performance due to the exponential number of elements created in the data structure during execution. We detect limitation in execution of MCS that included MCG with 5 parameters due to Out Of Memory error.

Error! Unknown

Chapter 6. Future enhancements


6 Future enhancements Future enhancements – what else can be done? 1. Abstraction of the programs (concrete program is replaced with an abstract one, which is independent

of the programming language). For example: Supplying a C program as input will 1) convert the concrete program to abstract MC system; and 2) calculate RF of the abstract program.

2. Implement the MC analysis on the set of integers set that is not well ordered – allow also analysis of program that uses also the negative whole numbers.

3. Adding tool for verifying the RF correctness – A preliminary tool was written in Matlab by Amir Ben Amram. It can be found in the utilities folder supplied with the MC software. Note: The test program cannot process external files and the input has to be inserted manually in internal representation.

Error! Unknown

Chapter 7. Examples Book


7 Examples Book This chapter introduces some interesting input examples and show various aspect of the Ranking Function Algorithm and of the technical aspect of our MC software.

All the examples can be found in the examplesBook\ folder enclosed with the MC SW.

Basic Ackermann example - ack.csl Presented in the chapter “Ranking Function Algorithm”.

Program contains functions with varied parameters number

Figure 29): F3ParG2Par.csl

Describe the SW ability to support functions with varied number of parameters in the same program.

Permuted variables ensure termination - FtoF_XdecYTagYDEQXTag.csl Already described in the introduction.

Single MCG contains permuted variables from F to F. composition of such MCGs creates multipath with descent thread .

Result RF:

,0, , 2, 0, , 0, 0, , 1,

On demand versus In advance – elaborationOnDemand.csl Displayed on the chapter Elaboration On demand versus In Advance

Fail to calculate RF of a non terminating example

Figure 30): FtoFNonTerminating.csl

Error! Unknown



The algorithm fails to calculate the example’s RF due to inexistence of MTP of some SCC. This is example of a non terminating program.

Hint for the non termination could be deduced from the arcs of the first MCG, composition of this MCG with itself can create infinite loop without descent.

Fail to calculate RF of a non terminating example with 3 MCGs

Figure 31): nonTerminating3MCGs.csl

The example shows the following:

1. The algorithm fails to calculate the example’s RF due to inexistence of MTP of some SCC. Hint for the non termination, could be deduced from the arcs of the first MCG, composition of this MCG with itself can create infinite loop without descent.

2. Elaboration results with unsatisfiable MCGs that are removed.

Figure 32): unsatisfiable elaborated MCG a b MCG index: 1

3. Elaboration on demand avoids from elaborating redundant unreachable MCGs:

Elaboration In Advance Elaboration On Demand

Figure 33): Elaboration in advance Vs. Elaboration on demand.

MCG with 4 parameters The input:

{(f f {(x x' deq) (x y' dec) (z z' dec)}), (f f {(y y' deq) (y x' dec) (w w' dec)})}

Error! Unknown



Result with RF of 75 entries.

Execution time is: 5 seconds elapsed time.

System details:

Processor: Intel (R) Core (TM) 2 Duo CPU 2.1 GHz)

Memory RAM: 3546MB.

System type: 32 bit

OS: Windows Vista

Java: JDK 1.6

JVM arguments: -Xms64m -Xmx1024m - using maximum heap size of 1GB RAM.

MCG with 5 parameters

Input MCGs in CSL format:

{(f f {(a b' dec) (b c' deq) (c d deq) (d’ e deq) (e’ a’ deq)}) }

Figure 34): MCG with 5 parameters.

This example contains 5 parameters, fails on Out Of memory.

MCG with negative cycle in input stage Our basic Ackermann example + additional inconsistent MCG that will be removed due to negative cycle exception

Figure 35): ackInconsistentNegativeCycle.csl

Error! Unknown



The 3rd MCG is inconsistent since it contains negative cycle.

Prior elaboration step, the inconsistent will be removed.

MCG with negative cycle found in elaboration stage – ackInconsistentNegativeCycleInElaboration.csl In this example there are no inconsistencies in the input MCGs. However, during elaboration of the MCG there are a few invariants that cause inconsistencies, hence those inconsistent MCGs will be removed from the elaborated system.

Figure 36): MCG with negative cycle found in elaboration stage – ackInconsistentNegativeCycleInElaboration.csl

Program with two different functions - ackBack.csl Similar to the basic Ackermann example, but using two functions instead of one (second function name is back).

Figure 37): MCG Program with two different functions - ackBack.csl

Error! Unknown



The ranking function is given by:

,0, , 1, 0, , 0, 0, , 2,

,0, , 4, 0, , 5, 0, , 3,

Functions with unique variable names - ackBackXYAB.csl

Figure 38): Functions with unique variable names - ackBackXYAB.csl

Similar to ackBack.csl, but uses x and y as parameter names for and and as parameters for .

Display the technical aspect that every function has its own variables. This example result with the same ranking function as previous example.

The ranking function is given by:

, 0, , 1, 0, , 0, 0, , 2,

, 0, , 4, 0, , 5, 0, , 3,

MCG with increase arc in input translated into decrease arc - ackUsingINCinsteadOfDEC.csl

Show the technical aspect that we support also increase arcs in the input that are being translated into decrease arcs.

The input MCGs :{ (ack ack {(x' x inc)}), (ack ack {(x x' deq) (y' y inc)})} Treated as it was: {(ack ack {(x x' dec)}), (ack ack {(x x' deq) (y y' dec)})}

Error! Unknown



Figure 39): MCG with increase arc u←v in input translated into decrease arc v→u - ackUsingINCinsteadOfDEC.csl

Median Ranking Function – median.csl

Presented in the chapter “Example RF – Median RF” Input MCGs in CSL format:

{(f f {(x1 x1' deq) (x1 x2' deq) (x2 x1' deq) (x2 x2' dec)}), (f f {(x1 x1' dec) (x1 x3' dec) (x3 x1' dec) (x3 x3' dec)}), (f f {(x2 x2' deq) (x2 x3' deq) (x3 x2' deq) (x3 x3' dec)}) }

3 MCGs composed of function with 3 parameters – median.mc

Input MCGs in MC format:

f(x1, x2, x3) :- [x1>=y1, x1>=y2, x2>y2, x2>=y1] ; f(y1, y2, y3). f(x1, x2, x3) :- [x1>y1, x1>y3, x3>y1, x3>y3] ; f(y1, y2, y3). f(x1, x2, x3) :- [x2>=y2, x2>=y3, x3>=y2, x3>y3] ; f(y1, y2, y3).

This example shows two aspects:

1. The SW ability to handle input in MC format. (Convert to CSL prior fetching the MCGS into

objects).

The conversion changed the variables names:

The parameter name prefix of is its related function and the suffix is its variable index in the

original function.

Figure 40): 3 MCGs composed of function with 3 parameters each converted from MC format – median.mc

Error! Unknown



2. Example of 3 MCGs with 3 parameters. a. result ranking function:

_1, _2, _3

0, _2 , 2, _1 _2 _30, _3 , 4, _1 _2 _30, _2 , 3, _1 _2 _30, _3 , 5, _1 _2 _30, _3 , 6, _1 _3 _20, _3 , 0, _1 _3 _20, _1 , 11, _2 _1 _30, _3 , 12, _2 _1 _30, _3 , 9, _2 _3 _30, _3 , 7, _2 _3 _10, _1 , 1, _3 _1 _20, _2 , 10, _3 _1 _20, _2 , 8, _3 _2 _1

Error! Unknown


8 Conclusion We reviewed the MCS abstraction, an extension of the Size-Change Termination framework, describing some of the theory of MC and the construction of global ranking functions in singly-exponential time (which improves on previously-published work even for SCT). A key technique is elaboration, using state invariants to separate out the behavior under different assumptions on the relative order of variables. The contribution of this project is the implementation of Algorithm 6.15[1] in Java. The tool receives as input abstract programs and automatically analyze whether the program terminates and provides a ranking function that can be used for running-time analysis. So far, only a preliminary empirical evaluation, using basic simple examples, has been done. As expected, memory fills up quickly when the number of variables is enlarged. It seems clear that in a practical implementation, both for deciding termination and for constructing ranking functions, avoiding unnecessary combinatorial explosion is imperative. Some tactics that might possibly improve scalability appear in [1] section 8. Finally, probably the most appealing aspect of MCS, compared to the SCT abstraction, is its usefulness in the integer domain. A possible extension of this project may implement the solution for the integer domain [7]. Implementation of such a system would increase the applicability of the tool for practical software verification tasks.

Error! Unknown

Chapter 9. References


9 References

[1] Amir M. Ben-Amram. Size-Change Termination, Monotonicity Constraints and Ranking Functions, In Logical Methods in Computer Science, 6(3), 2010. [2] Amir M. Ben-Amram and Chin Soon Lee. Size-change analysis in polynomial time. ACM Transactions on Programming Languages and Systems, 29(1), 2007. [3] Alexander Krauss. Certified size-change termination. In Frank Pfenning, editor, 11th International Conference on Automated Deduction (CADE), volume 4603 of LNAI, pages 460–475. Springer-Verlag, July 2007. [4] Chin Soon Lee, Neil D. Jones, and Amir M. Ben-Amram. The size-change principle for program termination. In Proceedings of the Twenty-Eighth ACM Symposium on Principles of Programming Languages, January 2001, volume 28, pages 81–92. ACM press, January 2001. [5] Michael Codish , Vitaly Lagoon and Peter J. Stuckey. Testing for Termination with Monotonicity Constraints. In Logic Programming, 21st International Conference, ICLP 2005, volume 3668 of LNCS, Pages 326-340. Springer-Verlag, October 2005. [6] Amir M. Ben-Amram and Chin Soon Lee. Ranking functions for size change termination II. Logical Methods in Computer Science, 2009. 5(2),2009. [7] Amir M. Ben-Amram. Monotonicity Constraints for Termination in the Integer Domain, In preparation, 2010.

Error! Unknown
