Monotonicity and the Precision of Program Analysis

It is widely known that the precision of a program analyzer is closely related to intensional program properties, namely, properties concerning how the program is written. This explains, for instance, the interest in code obfuscation techniques, namely, tools explicitly designed to degrade the results of program analysis by operating syntactic program transformations. Less is known about a possible relation between what the program extensionally computes, namely, its input-output relation, and the precision of a program analyzer. In this paper we explore this potential connection in an effort to isolate program fragments that can be precisely analyzed by abstract interpretation, namely, programs for which there exists a complete abstract interpretation. In the field of static inference of numeric invariants, this happens for programs, or parts of programs, that manifest a monotone (either non-decreasing or non-increasing) behavior. We first formalize the notion of program monotonicity with respect to a given input and a set of numerical variables of interest. A sound proof system is then introduced with judgments specifying whether a program is monotone relatively to a set of variables and a set of inputs. The interest in monotonicity is justified because we prove that the family of monotone programs admits a complete abstract interpretation over a specific class of non-trivial numerical abstractions and inputs. This class includes all non-relational abstract domains that refine interval analysis (i.e., at least as precise as the intervals abstraction) and that satisfy a topological convexity hypothesis.


INTRODUCTION
Static program analysis has been widely investigated and used to help programmers and software engineers in producing reliable code [Distefano et al. 2019;O'Hearn 2018;Rival and Yi 2020;Sadowski et al. 2018].Static analysis relies on symbolic reasoning and over-approximation to reason on program behaviors and to verify correctness speci cations, also known as safety properties, without actually executing the programs.For instance, common safety speci cations are: "Variable is not negative" or "Variable ranges in the interval [ , ]".Given a program , a correctness speci cation Spec and a set of inputs , a static analyzer either proves that the execution of on satis es Spec, also written ⊆ Spec, or it raises some alarms.Abstract interpretation [Cousot and Cousot 1977, 1979, 1992, 2014] generalizes most existing static analysis methods into a unique sound-by-construction framework based on a simple but striking idea that extracting properties of programs' execution means over-approximating their semantics.Given an abstract domain A representing the properties of interest ordered by a partial order ≤ A , we denote with A and A respectively the abstraction and concretization maps associated with A, and with • A an abstract interpreter de ned on A and computing the abstract semantics of a program.Let us assume that Spec is expressible in A, namely Spec = A ( A ( )).In this case, the abstract interpreter is sound when A A ( ) ≤ A A (Spec) implies ⊆ Spec.However, due to the spurious elements introduced by the abstract interpreter, it may happen that A A ( ) ≰ A A (Spec) even if ⊆ Spec.In this case the elements in A ( A A ( )) ∖ Spec are called false-alarms.We have completeness when no false-alarms are raised when verifying Spec: in this optimal case, proving ⊆ Spec by executing the program is the same as checking whether A A ( ) ≤ A A (Spec) holds, namely, ⊆ Spec ⇔ A A ( ) ≤ A A (Spec).Completeness represents an ideal and rare situation where there is no loss of precision between the abstract and concrete interpretation up to the abstraction chosen, and therefore the analysis is precise.Previous works have investigated the features of abstract domains and of programs under analysis that make an abstract interpreter complete.
It has been proved that completeness is possible only if the Best Correct Approximation (BCA) • A of the concrete semantics of on A is complete [Cousot and Cousot 1977;Giacobazzi et al. 2000].This means that, given a program , completeness is a domain property and domain re nements have been proposed in order to minimally transform abstraction A to gain completeness with respect to [Bruni et al. 2022;Giacobazzi et al. 2000].Observe that the BCA relies on the concrete program semantics and, in general, it may not be directly used to implement an abstract interpreter, therefore further abstractions are needed.This means that the BCA • A is more precise than any other abstract interpreter • A on A. Thus, the BCA represents the mathematical limit on the best precision that we can reach in abstract interpretation.
Furthermore, it has been shown that the completeness of an abstract interpreter with respect to a program is strictly in uenced by the way is written, namely, precision in abstract interpretation is an intensional program property [Bruni et al. 2020[Bruni et al. , 2021;;Giacobazzi et al. 2015].This is not hard to observe, in fact it is well known that code obfuscation [Collberg and Nagra 2009] refers to syntactic program transformations explicitly designed to degrade the results of program analysis, namely to induce imprecision, and therefore incompleteness [Dalla Preda and Giacobazzi 2005;Dalla Preda et al. 2006;Giacobazzi 2008;Giacobazzi and Mastroeni 2012;Giacobazzi et al. 2017].
In this paper we investigate the class of programs that can be precisely analyzed, namely, admitting a complete abstract interpretation, over a speci c family of non-trivial abstract domains and inputs.We focus our study on the analysis of numeric properties of program variables, thus considering numerical abstract domains.Exploring the possibility for programs to be precisely analyzed means that we need to refer directly to the BCA of A and not to a generic (less precise) abstract interpreter.This turns the focus on the concrete semantics of the program, from which the BCA derives.Note that the program equivalence induced by the BCA on an abstract domain A, namely is equivalent to if and only if A = A , is an extensional equivalence, namely a property related to what a program computes and not to how it is written.
The Intuition.There are programs whose extensional behavior, namely their input-output relation, guarantees the existence of a complete abstract interpretation on a given abstract domain, whereas others deny this possibility as witnessed by the following examples.Consider the simple Observe that in these latter cases ABS is monotone on the considered input, decreasing if negative (e.g., on 2 ) or increasing if positive (e.g., on 1 ), while ReLU is always monotone (speci cally non-decreasing) on all inputs.
Few questions naturally arise from these two examples: Is there a relation between the monotonicity of programs and the completeness of the analysis on an abstract domain and input?If yes, is there a way to locate program fragments that behave monotonically for a given set of inputs?
Main Contribution.In this paper we formalize and study two central notions: the notion of monotone program, adapting the standard mathematical notion of monotonicity to programs, and the notion of complete-analyzability, identifying all programs admitting a complete abstract interpretation on a given abstract domain and set of inputs.Our contribution is twofold: (1) we de ne a proof system able to soundly verify whether a set of program variables behaves monotonically, namely either non-decreasing or non-increasing, in the portion of program under inspection and on the given set of inputs; (2) we establish a relation between program monotonicity and the completeanalyzability property: the monotonicity of a program is a su cient condition that guarantees the possibility of designing a precise abstract interpretation for it, over a speci c collection of numerical abstractions and inputs.
After introducing some basic mathematical notions, a simple imperative language and some background on abstract interpretation (Section 2), we start with Section 3 by providing a formal de nition of program monotonicity (either non-increasing or non-decreasing) with respect to a set of numerical variables and inputs of interest.Then, we present a proof system designed to verify whether a program is non-decreasing with regard to a speci c set of variables and a set of inputs.The proof judgments have the form ↗ ( , , ) meaning that program is nondecreasing on the set of inputs with respect to variables in (the judgments ↘ ( , , ) for the non-increasing case follow by duality).Our proof system is sound, meaning that all derived monotonicity judgments correspond to e ectively monotone code.Similar to the analysis of program continuity [Chaudhuri et al. 2010] and di erentiability [Beck and Fischer 1994], the major challenge in proving monotonicity arises from branches, namely conditional statements if then 1 else 2 and loops while do .Our idea is to restrict the analysis to the Boolean guards made by only predicates of the form ≤ 0 where expression is positive linear, i.e., has the form |Var ( ) |

+
where is a program variable, ∈ R ≥0 , ∈ R and |Var ( )| represents the number of variables occurring in .In this scenario, for the if-statements, whenever the two branches 1 and 2 are proved non-decreasing, it is su cient to check the non-decreasing property on boundary states, i.e., those states that satisfy the equation = 0 for the predicates ≤ 0 occurring in .A similar reasoning is applied when Boolean guards are composed by only predicates in the form ≥ 0. For example, ReLU is non-decreasing on variable at any input as the branches := 0 and := are non-decreasing, and the order is preserved on the boundary state = 0 after the execution of both branches: := 0 (0) ≤ := (0).This idea resembles the continuity check on if-statements presented in [Chaudhuri et al. 2010] where boundary states are checked to preserve the same values after the execution of each branch whereas, for the non-decreasing case, we check that the order is preserved.A similar approach is employed for loops, where the notion of boundary states is re ned giving rise to the notion of limit states.
In Section 4 we investigate the relation between monotonicity and complete-analyzability.In particular, when a program is monotone for a set of variables , it is possible to characterize a class of non-trivial numerical abstract domains and sets of inputs where the BCA of is complete on them when analyzing variables in .These abstract domains are non-relational abstractions that re ne interval analysis (i.e., at least as precise as intervals) and satisfy a topological convexity condition.This result explains why we have no false-alarms when using ReLU Int for checking numerical properties of ReLU expressible in the interval abstraction.Moreover, as composing monotonically non-decreasing (resp.non-increasing) programs preserves the non-decreasing (resp.non-increasing) property, the complete-analyzability property also holds on the composition.For example, the program ReLU; Bin made by composing ReLU and the non-decreasing binary step program Bin def = if < 0 then := 0 else := 1 preserves the complete-analyzability property.To the best of our knowledge, the results presented in this paper establish for the rst time a relation between an extensional program property (monotonicity) and the possibility of designing a precise abstract interpretation, con rming the intuition that precision in abstract interpretation, although intensional, has also an extensional aspect, namely it is in uenced not only by how programs are written but also by what they compute.For instance, changing the implementation of ReLU into the semantically equivalent (on Z) program ReLU def = while < 0 do := + 1 does not change the complete-analyzability of the program: ReLU is still monotonically non-decreasing on its variable therefore it can be precisely analyzed on the interval abstract domain.This aspect sheds new lights on the existence of provably complete abstract interpreters over a family of (non-trivial) abstractions for a restricted (non-trivial) class of programs, namely, the monotone programs.The complete-analyzability property could play an important role in verifying safety-critical properties of (parts of) programs, such as runtime errors in avionics software [Bertrane et al. 2011[Bertrane et al. , 2015]], where even false-alarms are not admissible.Our proof system may help in factorizing programs in sub-components that behave monotonically.On these sub-components, precise program analyses can be obtained by using computationally less expensive non-relational abstract domains, such as the intervals abstraction.

PRELIMINARIES
After introducing some preliminaries on sets and order theory, in Section 2.1 we de ne a simple untyped deterministic while-language and its collecting denotational semantics, while in Section 2.2 we provide a recap of the necessary background on the abstract interpretation framework.

Programs and Semantics
Order Theory.Given two sets and , ℘( ) denotes the powerset of , the symbol ∅ corresponds to the empty set, ∖ denotes the set-di erence, | | denotes the cardinality of , ⊆ denotes sets inclusion while ⊂ denotes strict sets inclusion.We denote with N, Z and R the sets of all, respectively, natural, integer and real numbers, and with I ∈ {N, Z, R} one of the three mentioned sets.A set ⊆ R is convex when, for all , ∈ and for any scalar ∈ [0, 1], the vector (1 − ) + is also in .Although the notion of convexity does not directly apply to sets of integers, we misuse the term convex to indicate also when a set of (vectors of) integers ⊆ I exhibits a form of convexity.In this case, we refer to the de nition of integrally convex set [Yang 2009].Speci cally, a set of vectors of integers ⊆ Z is convex if any point in the convex hull (which is a subset of R ) of can be expressed as a convex combination of the points of that are "near" , where "near" means that the (Euclidean) distance between each two coordinates is less than 1.So for instance, the set {0, 1, 2} is convex because it represents a consecutive sequence of integers without "holes", which is not the case for {0, 1, 2, 5} as the integer numbers 3 and 4 are missing.When a binary relation ∼⊆ × is de ned over a set which di ers from N, Z and R, we will use the subscript ∼ except for the straightforward equivalence relation =.A set endowed with a partial order relation ≤ is called a partially ordered set, or brie y poset, and it is denoted by ⟨ , ≤ ⟩.Its strict version is denoted by the symbol < such that for all , ∈ , < if and only if ≤ and ≠ .We will consider posets for which all subsets ⊆ have a unique join, also called least upper bound (lub), denoted , and a unique meet, also called greatest lower bound (glb), denoted .The tuple ⟨ , ≤ , ∨ , ∧ , ⊤ , ⊥ ⟩, where ⊤ and ⊥ are, respectively, the greatest (top) and least (bottom) elements in , while ∨ and ∧ are, respectively, the lub and glb binary operators, is called a complete lattice.
is monotone if it is either non-decreasing or non-increasing.■ The composition of two functions . The Knaster-Tarski theorem guarantees that if is a complete lattice and : → a monotone function, then the set of xpoints of in is also a complete lattice.As a consequence, since complete lattices cannot be empty (they must contain the supremum of empty set), the theorem guarantees the existence of at least one xpoint of , and even the existence of a least (or greatest) xpoint, denoted lfp( ) (resp.gfp( )).Moreover, if : → is (Scott) continuous, i.e., preserves lubs of chains in , then lfp( ) = ∈N (⊥ ), where, for all ∈ N and ∈ , is inductively de ned by: 0 ( ) def = and +1 ( ) Syntax and Semantics.For our purposes we consider a standard untyped deterministic whilelanguage Prog with no runtime errors, as e.g. the one de ned in [Winskel 1993], with the syntax where ⋖ ∈ {<, ≤}, ⋗ ∈ {>, ≥} and, by abusing notation, Var is both used to denote a denumerable set of variables and, when applied to a program ∈ Prog, denotes the ( nite) set of variables in the text of , namely, Var : Prog → ℘(Var).Similarly, when applied to arithmetic and Boolean expressions, Var ( ) and Var ( ) denote the variables appearing in those expressions.We sometimes abbreviate operations like 2 * and * to, respectively, 2 and 2 .From now on and in the rest of the paper, whenever we talk about a program ∈ Prog, we assume |Var ( )| = , unless otherwise speci ed.A store for is a total function from variables in the text of to their values, namely, : Var ( ) → I.A store can be equivalently speci ed as a -tuple ( 1 , . . ., ) ∈ I where for all ∈ [1, ] and Var ( ) = { 1 , . . ., }, ( ) = , therefore I |Var ( ) | is the set of all possible stores for .Most of the examples shown in the paper consider programs with Var ( ) = { , , }, so that, a tuple like (10, 2, 5) ∈ I 3 corresponds to the store such that ( ) = 10, ( ) = 2 and ( ) = 5.A single store update is written [ ↦ → ].We will omit the subscript to when it is clear from context.The semantics of arithmetic and Boolean expressions of is de ned by the functions, respectively, e : I → I and b : I → { , } whose de nitions are straightforward and therefore omitted.The collecting semantics of arithmetic and Boolean expressions is respectively de ned by the functions e : ℘(I ) → ℘(I) and b : ℘(I ) → ℘(I ) de ned as: } so that b ⊆ lters the stores of making b true.The collecting denotational program semantics is : ℘(I ) → ℘(I ) and it is de ned in Fig. 1, where the operator ¬ b transforms the Boolean expression b into its negate.It is the standard predicate transformer semantics (also called strongest postcondition semantics) since ∈ ℘(I ) turns out to be the strongest store predicate for the store precondition ∈ ℘(I ).The terminology "collecting semantics" comes from the fact that for all ∈ Prog, : ℘(I Given ∈ ℘(I ) and ♯ ∈ A , then A ( ) and A ( ♯ ) can be de ned as, respectively: In what follows, we abuse notation and drop the superscript in A , A , A , ⊥ A , ⊤ A and ≤ A as it will be clear from the context.The following are examples of non-relational abstractions in Abs(℘(I))1 .
Example 2.2.The classical pedagogical examples include the abstract domains Sign def = {I, −, 0, +, ∅} and Parity def = {Z, even, odd, ∅} for, respectively, sign and parity analysis of numerical variables.These are straightforward non-relational abstractions of ⟨℘(I), ⊆⟩ [Cousot and Cousot 1976], namely, Sign ∈ Abs(℘(I)) and Parity ∈ Abs(℘(Z)), where the order relation ≤ Sign is de ned as ∅ < Sign 0 < Sign − < Sign I and ∅ < Sign 0 < Sign + < Sign I, while ∅ < Parity even < Parity Z and ∅ < Parity odd < Parity Z.The abstraction maps Sign : ℘(I) → Sign and Parity : ℘(Z) → Parity are de ned as follows: where mod is the integer modulo operation.♦ Example 2.3.The interval abstraction Int [Cousot and Cousot 1976] is an e cient and useful nonrelational abstract domain for deriving bounds to numerical variables, e.g., the absence of arithmetic over ows or out-of-bounds array accesses.Let I * def = I ∪ {−∞, +∞} and assume that the standard ordering ≤ on I is extended to I * in the usual way.Hence Int Note that Int preserves arbitrary unions in ℘(I) and therefore gives rise to a GI.♦ Abstract Interpretation.Let : C → C be a concrete monotone (transfer) function (to keep notation simple we consider unary functions) and let ♯ : A → A be a corresponding abstract (transfer) function de ned on some abstraction A ∈ Abs(C).Then, ♯ is a correct (or sound) approximation of on A when A • ≤ A ♯ • A holds.If ♯ is correct for then least xpoint correctness holds, that is, A (lfp( )) ≤ A lfp( ♯ ) holds.When dealing with GIs between all abstract transfer functions that approximate a concrete one, we can de ne the most precise one.

De nition 2.4 (Best correct approximation). The abstract function
: A → A de ned as and Cousot 1977].An abstract function ♯ is precise when it is complete.

De nition 2.5 (Complete approximations over an input). Given an input ∈ C, an abstract function
This de nition of completeness is taken from the local completeness notion introduced by Bruni et al. [2021Bruni et al. [ , 2023]], which is a weakening of the standard notion of completeness requiring De nition 2.5 to hold over all possible inputs ∈ C [Cousot 2021;Giacobazzi et al. 2000].Since we deal with local properties only, namely, properties requiring to specify an input (e.g., completeness, monotonicity, convexity, etc.), we will simply omit the word "local" as the input will be always speci ed.Conversely, when we do not specify the input, we implicitly assume that the property holds for all possible inputs.Intuitively, when ♯ is an abstract transfer function on A used in some static program analysis algorithm, completeness encodes an optimal precision for ♯ at input , meaning that the abstract behavior of ♯ on A exactly matches the abstraction in A of the concrete behavior of .It turns out that the possibility of de ning a complete approximation ♯ of on some A ∈ Abs(C) and ∈ C only depends upon the concrete function , the abstraction A and the input , that is, ( ) is the only possible option as complete approximation of ( ), as stated by the following theorem [Bruni et al. 2021;Giacobazzi et al. 2000].
Theorem 2.6.Completeness of a sound abstract function ♯ over an input ∈ C holds if and only if Completeness and Static Verification.The abstract interpreter applied to a program ∈ Prog is speci ed by the function

abstraction of properties of interest and
A soundly approximates the concrete semantics on the abstract domain A. We denote with A : A → A the abstract interpreter given by the BCA and de ned as We are not going to further specify how the abstract semantics A is de ned, since, thanks to Theorem 2.6, in order to conclude that ).We will use the symbol • A for referring to a generic abstract interpreter without specifying the program.
The goal of a static analysis is to soundly answer some questions on the dynamic (concrete) execution of programs.More speci cally, given a program ∈ Prog, an input ⊆ I and a safety property (also called correctness property) Spec ⊆ I representable in our chosen abstract domain A, the aim of a static veri cation A A ( ) is either to prove ⊆ Spec, namely that the behavior of on input satis es Spec, or to raise some alerts that point out which circumstances may cause a violation of Spec.The presence of false alarms is in this case unavoidable due to the need of program veri ers A to over-approximate the program behaviour : this is an unavoidable consequence of the will to solve an otherwise undecidable analysis problem.However, when the abstract interpreter is proved to be complete on with input , namely when

A ( ) =
A A ( ), then proving ⊆ Spec by executing the program is the same as checking whether A A ( ) ≤ A A (Spec) holds, i.e. no false alarms can arise from checking the speci cation through the abstract interpreter: all the raised alarms are surely real.This is summarized by the following theorem: Theorem 2.7.If A is complete at the set of inputs ⊆ I and Spec ⊆ I is representable in A, then the following holds: A be complete at input , and Spec = A ( A (Spec)). (⇐) This implication is a direct consequence of the soundness assumption of A and it does not make use of the completeness hypothesis:

VERIFYING MONOTONICITY
In this section we: (1) adapt the notion of monotonicity to programs, and (2) verify whether a given set of program variables manifests a monotone behavior in the considered program on a speci ed set of inputs.This last point requires to understand how monotonicity is propagated during computation.
Let us start by de ning when a program can be considered monotone.De nition 2.1 already provides us the standard notion of monotonicity for functions over posets.Given a program ∈ Prog, its denotational semantics over singletons ∈ I |Var ( ) | can be considered as a function from ⟨I |Var ( ) | , ≤⟩ to ⟨I |Var ( ) | , ≤⟩ where here ≤ is the componentwise inequality between tuples (stores).This means that De nition 2.1 can also be adopted for de ning when a program preserves or reverses the order of its inputs.However, since programs may manipulate temporary variables or variables associated to computations that are not the target of our study, we may be interested in a notion of monotonicity that considers only a subset of program variables.For this reason we introduce the notion of -monotonicity that is parametric w.r.t. a nite set ⊆ Var of program variables.Let ∈ Prog be a program with |Var ( )| = variables, and ≤ be the elementwise inequality only for variables in and that also appear in Var ( ), formally, ∀ 1 , 2 ∈ I : and, similarly, = be the elementwise equality for .Further, let D ⊆ I be the domain of , namely, the set of input stores over which terminates:

De nition 3.1 ( -Monotone program).
The program ∈ Prog is said to be -non-decreasing (resp.-non-increasing) at inputs ⊆ I for the variables in ⊆ Var, if and only if for all 1 , 2 ∈ ∩ D the following condition holds: Intuitively, a program is -non-decreasing (resp.-non-increasing) for a set of variables ⊆ Var whenever for all comparable input stores w.r.t. and for which terminates, the execution of preserves (resp.reverses) the relative order of stores on variables in .There are no constraints on the result of computation from input states that are not comparable or on the values of variable not in : they can behave in a non-monotone way.
Example 3.2.Consider the sequential composition of the following assignments: : := 2 ; := + 1; := + Variables and increase monotonically their respective inputs, and is the sum of those two variables.This implies that each time we take two states 1 , 2 ∈ R 3 such that 1 ≤ { , , } 2 , after executing on both input states, the order is preserved: 1 ≤ { , , } 2 .Therefore, we can conclude that this program is { , , }-non-decreasing over R 3 .However, note that is not { , }non-decreasing: in this case we can consider states having the component change arbitrarily.
When we say that is -monotone (or -non-decreasing or -non-increasing) without specifying the set of input stores, we implicitly assume that is -monotone (or -non-decreasing or -nonincreasing) over all possible inputs I |Var ( ) | .Similarly, if we do not specify the set of variables, we implicitly assume for all variables used in the considered program.This last assumption also applies to ≤ and = when they are used for comparing stores. 55:11

Monotonicity Judgments
Given a portion of code, can we automate the process of proving whether a set of variables behave monotonically w.r.t.De nition 3.1?The general answer is no because our core language Prog is Turing-complete and monotonicity is an extensional program property, therefore undecidable [Rice 1953].For this reason, we propose a sound approximation by de ning a proof system able to infer, inductively from the program syntax, the monotonicity judgment ( , , ) meaning that program is -monotone w.r.t. the set of variables ⊆ Var and over a set of inputs2 .We write ⊢ ( , , ) when the proof system allows us to formalize a derivation for the monotonicity judgement ( , , ).We will show that the proposed proof system is sound, namely, ⊢ ( , , ) implies that ( , , ) holds.Our proof system computes an underapproximation of the sets of monotone variables: Since the analysis targets a Turing-complete language, the proof system is incomplete, i.e., it may happen that a program is -monotone but the veri er is not able to nd a derivation for proving it.
From the next section, we will focus our attention on the analysis of the -non-decreasing program property, also denoted by the predicate ↗ ( , , ) (the non-increasing case ↘ ( , , ) follows by duality).We start by providing the rules for expressions, assignments and command compositions (Fig. 2), then we proceed by treating programs with if-branches (Fig. 3) and while-loops (Fig. 5).

Expressions, Assignments and Sequential Compositions
To infer that := is -non-decreasing at , we need to verify that for all 1 , 2 ∈ ∩ D := it holds that 1 ≤ 2 ⇒ := 1 ≤ := 2 .For ∈ , we can soundly derive monotonicity whenever the following three conditions are satis ed: (1) the expression uses only variables in , i.e., Var ( ) ⊆ , (2) the set of inputs is convex, and (3) the gradient of the function : I |Var ( ) | → I, i.e., the column vector of all partial derivatives of denoted ) is always non-negative at all inputs in the convex space (for the mathematical notion of di erentiation of multivariate functions see, e.g., [Trench 2013]).Since our language Prog admits only polynomial expressions, all functions are di erentiable over I |Var ( ) | , namely, the gradient ∇ is always de ned and can be obtained by symbolic di erentiation.By requiring ∇ ≥ 0 |Var ( ) | ×1 , where 0 |Var ( ) | ×1 is the column vector of all 0s having number of rows equal to |Var ( )|, the result is a system of constraints on Var ( ), limiting the input states to only those that make the gradient ∇ non-negative [Trench 2013].
We give now an intuition of the other rules in Fig. 2. Rule (skip) does not modify the conclusion since no operations are involved.In addition, monotonicity trivially holds on any variable when either there is no input to consider (rule (empty )), or the program does not modify any variables of .This last condition is stated by rule (empty ) where ( ) represents the set of all variables that appear on the left side of an assignment in .
(weaken) observes that the non-decreasing program property of can be soundly weakened by restricting the set of input states at which monotonicity is asserted.Note that the weakening rule is only possible on the input states and not on the set of variables otherwise it may lead to unsound derivations.For instance, the program in Example 3.2 is { , , }-non-decreasing but not { , }-non-decreasing.Furthermore, observe that (weaken) does not require any convexity assumption on the weaker set ′ : whenever we can prove monotonicity on , then we are sure that any pair of states in satis es De nition 3.1, and, therefore, any subset ′ of .This fact turns out useful, e.g., when we want to prove non-decreasing an assignment over a non-convex set ′ : we may deduce rst that the assignment is non-decreasing over a convex overapproximation , i.e., such that ′ ⊆ ∧ ( ), through the rule (assign), and then apply (weaken) to come back to the non-convex set ′ .
The rule (seq) addresses sequential composition of programs.In domain theory (see, e.g., [Scott and Strachey 1971]), it is well known that the composition of two monotonically non-decreasing mappings : Here the result is similar, the only condition to verify is that all the output states of 1 on input 1 satisfy 2 , namely 1 1 ⊆ 2 .This condition is formalized in the premise of (seq) as the Hoare triple [Hoare 1969] { 1 } 1 { 2 }.If these premises are true, then we can safely conclude that the composition 1 ; 2 is -non-decreasing at all input states satisfying 1 .

If-branches
Challenges arise when programs contain if-statements or loops.In fact, similar to the analysis of program continuity [Chaudhuri et al. 2010] and di erentiability [Beck and Fischer 1994], the main source of non-monotone behaviors are branches.
Let us start by analyzing the if-statement if then 1 else 2 .The trivial cases here correspond to guards that are always satis ed (resp.not satis ed) by the considered input states , i.e., = (resp. = ∅): the conclusion is the analysis of 1 (resp.2 ).This is formalized by rule (if true ) (resp.(if false )) of Fig. 3.By considering now the non-trivial cases ( ≠ ∧ ≠ ∅), we would like to prove the -non-decreasing property of if then 1 else 2 provided that both 1 and 2 are -non-decreasing.Unfortunately, these assumptions are not su cient to guarantee the overall monotonicity of the if-statement.This is because two comparable states could ow along di erent branches, potentially resulting in non-monotone behavior.
Example 3.5.Consider the following program If we consider all inputs having ≥ 0, then both paths lead to non-decreasing programs: := 2 + 3 is { , }-non-decreasing for all ≥ 0, and := + 10 is always { , }-non-decreasing.The question is: because both branches are { , }-non-decreasing on all states R 2 satisfying ≥ 0, can we also conclude that is { , }-non-decreasing over all states R 2 satisfying ≥ 0? Consider two comparable input states 1 = (0, 0) and 2 = (2, 2) such that 1 ≤ { , } 2 .Then, if is { , }-nondecreasing, we would expect that 1 ≤ { , } 2 .But this is not true, as 1 = (0, 10) ≰ { , } (7, 2) = 2 .Note that 1 follows the then branch while 2 follows the else branch.♦ The optimal approach here would involve verifying that comparable states following di erent branches, do not violate monotonicity, i.e., ∀ 1 , 2 such that 1 ≤ 2 and ).This checking phase can be simpli ed when the guard is a positive linear guard: all Boolean predicates occurring in either have the form ⋖ 0 or they all have the form ⋗ 0, and = 0 is a positive linear equation, i.e., the expression can be written as = ) then every state that makes true is either less or equal (resp.greater or equal) or not comparable for variables Var ( ) with respect to the states that do not satisfy , i.e., ∀ 1 , 2 : if 2 ), or 1 and 2 are not comparable.
Example 3.7.The graphical representation of + − 2 ≤ 0 ∨ 2 + − 3 ≤ 0 ∈ + ⋖ of Example 3.5 is depicted in Fig. 4. By selecting any two states 1 , 2 such that 1 is in the green area (i.e., satisfying the guard) while 2 is in the white area (i.e., not satisfying the guard), we can be certain that either 2 or they are not comparable, in other words, it is never the case that 2 is less than 1 .♦ In this scenario, provided that 1 and 2 are -non-decreasing, in order to conclude the overall monotonicity of if then 1 else 2 , it is su cient to check the behavior of branches 1 and 2 at boundary states.Given ∈ + we formally de ne the set B ( ) of boundary states as follows: B ( ) Note that B ( ) represents an overapproximation of the true boundary states of .
Example 3.8.By considering again Example 3.5, the boundary states here are B ( + −2 ≤ 0∨2 + −3 ≤ 0) = + −2 = 0∨2 + −3 = 0 , namely, the set of points {( , ) | + −2 = 0 ∨ 2 + −3 = 0} solving either the equation + − 2 = 0 or the equation 2 + − 3 = 0. Note that this set contains more states than those actually on the guard + − 2 = 0 ∨ 2 + − 3 = 0 (the states on the blue and red lines of Fig. 4).♦ Rule (if) contains all the necessary pre-conditions for proving the non-decreasing behavior of ifstatements.Firstly, we have to prove that 1 is -non-decreasing at all states satisfying ∧( ∨B ( )), namely, the set of all program states in that either satisfy or are boundary states.The same applies for program 2 at states ∧ (¬ ∨ B ( )).Finally, for the case ∈ + ⋖ , it is su cient to check that the result of the computation of the true-branch 1 cannot exceed the result of the computation along the false-branch 2 on boundary states that are also in , i.e., it must hold ∀ ∈ ∧ B ( ) : 1 ≤ 2 .This condition is encoded by the following predicate: Note that the predicate Boundary treats also the case of ∈ + ⋗ : in this scenario, the execution of 2 must not exceed 1 on all states ∈ ∧ B ( ).This is the intuition behind rule (if) on Fig. 3. Practically, checking the above predicate could be done automatically by exploiting, e.g., a static analyzer based on abstract interpretation (e.g., [Cousot et al. 2005]).

Loops
Similar to if-statements, loops can easily break the monotonicity property, even when the loop body is monotone.This is because, given two comparable states ≤ ′ , an execution starting from may terminate earlier or later than the one starting from ′ , resulting in a potentially di erent outcome.
Example 3.11.Let us consider, for example, the while-loop while < 3 do := + 2. Although the assignment := + 2 is inherently non-decreasing for any input, the overall loop does not preserve the non-decreasing property.In fact, when the input is 0, the loop terminates after two iterations, whereas for input 1, it only requires one iteration to terminate.As a result, at the end of the execution, the program with input 0 surpasses the execution with input 1: while < 3 do := + 2 (0) = 4 ≰ 3 = while < 3 do := + 2 (1).♦ Since each iteration of while do can be viewed as an execution of if then else skip, when guards are positive linear we may think that the monotonicity of loops could be proved by employing the technique of the (if) rule.Regrettably, although sound, the use of boundary states B ( ) on loops is too weak as it fails to establish the monotonicity even for simple loops like while < 0 do := + 1.Indeed, for this example, requiring = + 1 (0) ≤ skip (0) for the boundary state = 0, is equivalent to demanding that the loop body does not modify variable .
For this reason, we need to re ne the de nition of boundary states for loops: instead of considering a set of states, we now consider a set of pairs of states ( 1 , 2 ), which we refer to as limit states.Intuitively, in the case of ∈ + ⋖ , the states ( 1 , 2 ) are limit states for the while-loop while do , when 1 enters the loop, 2 does not enter the loop and 1 ≤ 2 .We generalize this reasoning by de ning the following two sets based on a program , set of inputs , variables and, respectively, Given a while-loop while do such that ∈ + ⋖ , a set of input states , set of variables , and a loop invariant , the set of pairs of states L ⋖ ( , , ∨ , ) identi es our intuition of limit states.In this case, when ∈ + ⋖ , in order to conclude the overall non-decreasing behavior of the loop, we need to verify two conditions: (1) the loop body must be -non-decreasing on ∧ , and (2) for every pair of limit states ( 1 , 2 ) ∈ L ⋖ ( , , ∨ , ), the execution of with input the state Proc.ACM Program.Lang., Vol. 8, No. POPL, Article 55.Publication date: January 2024.
1 must not exceed 2 , namely it must hold that 1 ≤ 2 .These two conditions will ensure that, starting from two comparable stores ≤ ′ entering the loop, each execution of the body will not alter their order and, even if at some point, e.g., at the -th iteration, ′ exits the loop, where is the sequential composition of -times, the successive iteration of until it exists the loop, will not break the order.The condition (2) and its dual case when ∈ + ⋗ , are treated by the following predicate: This is the intuition underlying rule (while) in Fig. 5.The premise { ∧ } { } corresponds to the Hoare triple which states that is a loop invariant.Abstract interpretation can be employed to automatically detect a sound invariant.Rule (while ) addresses the straightforward scenario where none of the states in enter the loop.Practically, checking the validity of the predicate Limit ( , , , ), can be semi-automated by using modern automatic theorem provers or SMT solvers.
Proof.(skip): Since D skip = I , for any 1 , 2 ∈ such that 1 ≤ 2 , we get skip 1 = 1 ≤ 2 = skip 2 , therefore ↗ (skip, , ) holds for any ⊆ I and ⊆ Var.(empty ): is is equivalent to the emptyset of states = ∅.The monotonicity condition is trivially satis ed as there are no states to check, therefore ↗ ( , , ) holds for all ∈ Prog and ∈ Var.

ANALYSIS OF MONOTONE PROGRAMS
In this section, we show how monotonicity plays a central role in verifying numerical properties of variables by abstract interpretation.In particular, we identify certain structural properties of abstract domains and inputs that guarantee the existence of a complete abstract interpreter when analyzing variables that exhibit monotonic behavior in the program under analysis.An abstract interpreter • A is said to be complete for a program ∈ Prog and input ⊆ I when the equality A ( ) = A A ( ) holds.Note that this standard notion of completeness on abstract interpreters refers to all program variables used by .However, when dealing with non-relational abstractions, completeness can be speci ed with respect to a set of variables ⊆ Var which may be a subset of the variables actually utilized by the program under consideration.This gives rise to the notion of -completeness.
De nition 4.1 ( -Completeness).Let us consider a non-relational abstraction A ∈ Abs(℘(I )), a program ∈ Prog, an input ⊆ I and a set of variables ⊆ Var.We say that the abstract interpretation A of program is -complete at whenever the following condition holds for all ∈ ∩ Var ( ): Essentially, the -completeness property of abstract interpreters focuses on the analysis precision of a speci c set of variables, namely, the variables in .As the standard notion of completeness is equivalent to require Var ( )-completeness, if A is complete then it is also -complete for all ⊆ Var, while if A is -complete for ⊂ Var ( ) then it may be not complete.

Then, for any input,
Sign is { }-complete but not complete, i.e., not { , }-complete.Indeed, for all ∈ ℘(Z 2 ) we have Sign ( ) ♦ It is possible to relate monotonicity with the precision of program analysis when certain structural properties on the considered set of inputs and on the abstract domain are met.To this end, we introduce the notions of: (1) -bounded input, (2) Int-abstractable domain and (3) -convex domain.

De nition 4.3 ( -Bounded input).
The input set is said to be -bounded for the program when the following two conditions are satis ed: ( ) min ≠ ∅, and ( ) max ≠ ∅. ■ Intuitively, an input set is -bounded for the program when contains a minimum and a maximum store according to, respectively, min and max , and terminates for at least one store in min and max .While the notion of -boundness depends on the input (and on the program), the next two de nitions rely more on abstract domains.
De nition 4.5 ( -Convexity).An abstract domain A ∈ Abs(℘(I )) is -convex at for a program ∈ Prog, set of variables ⊆ Var and input set ∈ ℘(I ), if and only if for all ∈ ∩ Var ( ), ( A ( A ( )))( ) ∈ ℘(I) forms a convex set.■ Namely, the abstract set of values assumed by the program variable at the end of the concrete execution of with input , formally ( A ( A ( )))( ), must form a convex set, i.e. it must have no holes, and this must hold for all variables in that are also in the text of .Of course, abstract domains composed by only convex representations of elements of ℘(I), e.g.Int and Sign, are -convex for all ∈ Prog, ⊆ Var and ⊆ I .This does not hold in general for abstract domains composed by also non-convex abstract elements, e.g., Parity.However, it may happen that non-convex abstractions are -convex for some program and input .

De nition 4.7 ( -Complete-analyzability).
A program ∈ Prog is said to be -completeanalyzable for the non-relational abstraction A ∈ Abs(℘(I )), variables in ⊆ Var and input ⊆ I if and only if there exists an abstract interpreter • A such that A is -complete at .■ We use the predicate A ( , , ) to indicate that is -complete-analyzable for the abstract domain A at input .For instance, in Example 4.2 and ReLU de ned in Section 1 are, respectively, { }-and { }-complete-analyzable for, respectively, Sign and Int as the de ned analyses Sign and ReLU Int are, respectively, { }-and { }-complete for all inputs.The following result is a straightforward consequence of Theorem 2.6.Lemma 4.8.
A ( , , ) ⇔ A is -complete at .□ Starting from assumptions (1) and (2), we get: Note that, A non-relational and -convex at means that ( A ( A ( )))( ) corresponds to the interval [(min { } )( ), (max { } )( )] for all the considered variables in ˜ , i.e., all the 1dimensional lines having (min { } )( ) as minimum element and (max { } )( ) as maximum element, while the interval )))( ) for all ∈ ˜ because of the soundness property of abstract interpretation.Therefore, by the last derivation, we can conclude A ( ) = A A ( ), i.e., A ( , , ) holds, contradicting (5).□ Theorem 4.10 identi es speci c conditions on the input states and on the abstract domain that guarantee the existence of a program analysis that accurately captures the full behavior of a program.More speci cally, under the three assumptions of Theorem 4.10, the -monotonicity of program over the inputs A ( A ( )) is a su cient condition to ensure the -complete-analyzability of program at over the abstract domain A. This result reveals a connection between the extensional property of -monotonicity in programs and the completeness property of an abstract interpreter • A : the class of monotone programs represents a particular case over which it is possible to precisely (i.e., with no false positives and no false negatives) prove through • A all properties expressible in the abstract domains and over the inputs that satisfy the three conditions of Theorem 4.10.
Example 4.11.Monotone activation functions in neural networks (see, e.g., [Albarghouthi 2021]) are used to add non-linearity to the function computed by a neuron.The following three programs3 implement three well known activation functions: The Signum function maps negative input values to −1.The Sigmoid-weighted Linear Unit (SiL) [Elfwing et al. 2018] is used for neural network function approximation in reinforcement learning [Ramachandran et al. 2018].Their input-output relation is represented in Fig. 6.Let us consider the interval abstract domain Int on reals R, which has been extensively used for verifying properties of neural networks for, e.g., image classi cation [Gehr et al. 2018;Gowal et al. 2019], natural-language processing [Huang et al. 2019], and cyber-physical systems [Wang et al. 2018].It is easy to note that both Signum and ReLU are { }-non-decreasing programs and they can be easily veri ed with the proof system de ned in Section 3.This guarantees the existence of a complete analysis on Int for all possible bounded inputs since Signum Int and ReLU Int are complete.Furthermore, if the overall neural network is monotone, for example, when it consists of nondecreasing activation functions and each neuron implements a non-decreasing function, then Theorem 4.10 assures us the possibility to implement a complete static analyzer on bounded inputs for the Int abstract domain and, more generally, for any non-relational abstraction A that satis es De nition 4.4 and 4.5.This analyzer can accurately verify safety properties [Amodei et al. 2016] representable in A, at bounded sets of inputs.This result is not guaranteed when the overall neural network is not monotone, namely, when either a neuron or the activation functions used are not monotone, such as SiL.For instance, suppose that we want to check whether the variable at the end of the execution of SiL on the input set {−4, 0} ranges in the interval [−0.1, 0], and suppose we would like to check this speci cation using an abstract interpreter over Int able to answer this question with no imprecision.The concrete evaluation returns Int ( SiL {−4, 0}) ≃ [−0.07, 0], while the BCA on Int outputs SiL Int Int ({−4, 0}) ≃ [−0.28, 0].Note that SiL Int leads to a false-alarm since SiL Int Int ({−4, 0}) ≰ Int [−0.1, 0] even if the speci cation is satis ed: 1,0].This result excludes the possibility to de ne a complete analysis SiL Int over {−4, 0}.Nevertheless, if we consider an input set where SiL is monotone, e.g.{0, 4}, we have completeness: Int ( SiL {0, 4}) ≃ [0, 3.93] ≃ SiL Int Int ({0, 4})}, thus admitting the possibility to build a complete analysis for this input.♦ The converse of Theorem 4.10 does not hold, pointing out that the monotone condition is stronger than the notion of -complete-analyzability, as shown by the following example.
Example 4.12.Consider the following program : if ≠ 3 then := else := − 2. It is easy to note that this program is not monotone: it is not non-decreasing since 2 < 3 but (2) = 2 > 1 = (3), and not non-increasing since 2 < 4 but (2) = 2 < 4 = (4).Consider the input set {1, 5} and the Int ∈ Abs(℘(Z)) abstraction.Clearly, Int and {1, 5} satisfy the assumptions of Theorem 4.10.However, Int is complete at {1, 5}, therefore is complete-analyzable at {1, 5} even if is not monotone.♦ In the next three examples we show the reasons why the three assumptions of Theorem 4.10 are necessary.Assumptions (1), requiring that is -bounded, and (2), requiring that A is Intabstractable, are strictly correlated: if is -bounded and is -non-decreasing, then is -bounded and its minimum and maximum are precisely min and max (or reversed in case of non-increasing programs).Moreover, when A is Int-abstractable then all the spurious elements added by the abstraction over are enclosed by the minimum and maximum of .Indeed, the two assumptions are, in a sense, complementary: if is not -bounded, then even if A ≤ Abs(℘(I ) ) Int, A could add new maximum and minimum values for a variable ∈ at A ( A ( )) which may lead to incompleteness.This reasoning holds also for -bounded and A not representing intervals.The following example shows these corner cases.
Example 4.14.Consider the abstract domain P ⊓ I ∈ Abs(℘(Z)) which is the reduced product of Parity and Int abstract domains.P ⊓ I represents properties which are the intersection between intervals and even or odd numbers.For example, [0, 10] even represents {0, 2, 4, 6, 8, 10}, that is, all the even numbers in the interval [0, 10].Clearly, this abstract domain can represent non-convex properties, such as [0, 10] even .However, P ⊓ I is Int-abstractable because it can represent exactly all the intervals.Let us consider the following program: where we assume the mod operator is de ned in Prog.Let us consider the set of inputs {2, 5}.It is easy to note that is non-decreasing over P⊓I ( P⊓I ({2, 5})).Moreover, by the evaluations Unfortunately, the answer is negative.As a rst observation, because relational abstractions consider, as the name suggest, relations between variables, it is no longer possible to employ the notion of completeness modulo a set of variables (De nition 4.1).Instead, the standard notion of completeness is considered.Let us look at the case of 2-dimensional inputs, namely when Var ( ) = { , }.Firstly, note that the 2-dimensional abstraction shape of a relational Int-abstractable abstract domain able to infer a ne inequalities over a bounded set of inputs , will consist of edges having the form = 0 and = + with , ≥ 0. This is because, when considering bounded sets, has minimum and maximum points, A is at least as precise as Int, and, by assuming monotonicity, A ( A ( )) and A ( A ( A ( A ( )))) do not modify the order in A ( A ( )).So, for example, the Oct abstraction of a monotonic program over an input will result in the same shape as the Zone abstraction.However, it turns out that even monotonic programs can violate the completeness property over a bounded set for a relational abstraction.The following is a counterexample of Theorem 4.10 for the Zone ∈ Abs(℘(Z 2 )) abstract domain.Example 5.1.Consider a set = { , , , } of four symbolic points in two dimensions along the line = depicted on the left of Fig. 7.This set has minimum at and maximum at .The Zone abstraction Zone ( Zone ( )) adds one spurious element between and .The gure on the right represents a monotone transformation of the points in : essentially, the minimum and maximum are left invariant, while and points are monotonically moved downward, keeping the ≤-order unchanged since ≤ ≤ ≤ .The trapezoid having dashed blue edges represents the concrete abstraction Zone ( Zone ( )).If transforms the spurious point generated by the abstraction, as the red point on the right of Fig. 7, namely , then program is still monotonic over Zone ( Zone ( )) since ≤ ≤ .However, the shape outlined by Zone ( Zone ( )) di ers from the dashed blue trapezoid because of : this point adds the region surrounded by the red dashed line.This implies that, even if is non-decreasing over Zone ( Zone ( )), Zone is not complete at .In fact, it turns out that could move to any point in the orange region of Fig. 7 in order to keep monotonicity and break completeness.♦ Relational abstract domains may disclose hidden relations between variables which may violate the complete-analyzability property over a bounded set , even when all program variables behave monotonically.A better understanding of which operators (or weakening) preserve the completeanalyzability property is necessary, which we leave as a future work.

RELATED WORK
In the literature, there are many works exploring the role of monotonicity in programming languages (mostly referring to the non-decreasing case only).One of the most prominent and classical use of monotonicity is to guarantee the existence of a minimal xpoint and termination of functions when certain conditions are satis ed.This goes back to the Knaster-Tarski xpoint theorem [Tarski 1955] and its extensive uses, e.g., in program analysis [Nielson et al. 2015], or as the bases for de ning programming languages such as Datafun [Arntzenius and Krishnaswami 2016] and Flix [Madsen et al. 2016].In particular, Arntzenius and Krishnaswami [2016] track monotonicity of the functional language Datafun with the aid of a type system which has some similarities with our proof system.In Datafun variables could be declared monotone by users guiding the type system in recognizing monotone functions.Conversely, our aim is to inductively nd monotone variables starting from a piece of code without any prior knowledge.Their type system di ers from ours as their de nition of monotonicity is slightly di erent: in their case a program is -monotone when for every pair of stores that share the same values of variables not in , the order of variables in is preserved after the execution of the program (while we do not have any constraints on the variables not in ).Moreover, their rules for the if-statement consider two simple cases: the guard does not use monotone variables, or the false-branch corresponds to the least element.
Monotonicity is of key importance also in separation logic [Ahman et al. 2018;Pilkiewicz and Pottier 2011;Timany and Birkedal 2021] for reasoning about concurrent programs.Here monotonicity is used with respect to some relation as requirement on modules, for example a program module may need to know that the computation performed on the shared memory by other modules always amounts to progress in some monotone way.This is in contrast with the goal of our proof system where monotonicity is not a requirement but it is a property of variables that we want to discover in order to derive the complete-analyzability property.
Other uses of monotonicity lie also in distributed programming [Alvaro et al. 2011;Conway et al. 2012] to guarantee that nodes in a distributed database eventually agree [Vogels 2009].Conway et al. [2012] propose a simple analysis for identifying possible non-monotone code locations of programs written in Bloom (an extension of the Bloom [Alvaro et al. 2011] declarative programming language incorporating a join-semilattice with built-in monotone functions).The monotonicity analysis here is carried out through a predicate dependency graph which is based on a simple program syntax test: locations where an asynchronously computed value is consumed by a non-monotone operator, are classi ed "at risk".Monotone operations are just a list of monotone functions de ned by the lattices used by the current program.
The mathematical notions of continuity and di erentiability are related to monotonicity, even when considering programs.Continuity has been extensively studied for programs [Chaudhuri et al. 2010] since it is a precursor for verifying their robustness [Chaudhuri et al. 2011].Although monotonicity and continuity are di erent properties, the proof system de ned in [Chaudhuri et al. 2010] for verifying continuity has some similarities with ours for monotonicity: both if rules consider boundary states for proving the respective property on branches.Chaudhuri et al. [2010] check that the true-and false-branches agree at boundary states on the considered variables (called -equivalence), while for those states we check that the order is preserved (thanks to the positive linearity assumption of the guard).Furthermore, program continuity could be used as a su cient condition for proving monotonicity on branches: roughly, by considering the nondecreasing case, if both branches are non-decreasing and the overall if-statement is proved to be continuous, then the if-statement is also non-decreasing as the -equivalence on borders ensures the order of boundary states is not violated.Also di erentiability has been studied in programming languages [Abadi and Plotkin 2020;Beck and Fischer 1994;Ehrhard and Regnier 2003;Elliott 2018] as it plays a prominent role in modern machine learning.Although the di erentiability property can be exploited for verifying monotonicity of expressions (see (assign) rule), our proof system does not require di erentiability of the branches, as this would be a stronger condition (there are non-di erentiable functions that are monotone, e.g., ReLU).
The Interval Universal Approximation Theorem (IUA) [Baader et al. 2020;Wang et al. 2022] relates (computable) continuous function to provably robust neural networks through interval analysis.IUA guarantees that it is possible to nd a provably robust neural network approximating a continuous function.We are relating, instead, the (extensional property) monotonicity of a program (namely, a computable monotone function) with the existence of a provably complete analysis over it on a restricted class of non-relational domains and inputs, without passing through the phase of nding a new complete-analyzable program ′ semantically equivalent to .Nevertheless, these two results may hide interesting connections which deserve further investigations.
To the best of our knowledge, this is the rst time that a relation between monotonicity (either non-decreasing or non-increasing) and the precision of program analysis has been established.Previous work in program analysis (e.g., by Giacobazzi et al. [2015] and Campion et al. [2022b]) shows that the precision of a program analyzer is strictly correlated to how programs are written.Our de nition of -completeness is based on the well known notion of completeness [Giacobazzi et al. 2000] and local completeness [Bruni et al. 2021[Bruni et al. , 2023]].Although it has been proved that completeness and its weakening are non-decidable program properties [Campion et al. 2022b;Giacobazzi et al. 2015], we showed that if a program is monotone then this fact is a su cient condition for proving completeness of the BCA over a speci c family of abstractions and inputs.

DISCUSSION
Completeness in abstract interpretation is in uenced not only by how programs are written but also by what they compute.It is therefore an interesting mix of intensional and extensional program properties that impact the precision of program analysis.While the intensional nature of completeness in abstract interpretation has been recently investigated [Bruni et al. 2020;Giacobazzi et al. 2015], less is known about its extensional nature.We established a relation between extensional program properties and the precision of program analysis.Monotone programs are an interesting case study delimiting the precision of some non-relational abstractions.On sub-components that behave monotonically, speci cations Spec expressible on abstract domains satisfying the hypothesis of Theorem 4.10 can be proved with no false alarms (Theorem 2.7) by using some computationally less expensive non-relational abstract domains (e.g., Int).In case Spec is not expressible, we can always overapproximate in that domain.Our result ensures the existence of a complete abstract interpreter that generates no additional false alarms with respect to this overapproximation over bounded inputs.Furthermore, the complete-analyzability property could support static analysis in the context of obfuscated programs [Collberg and Nagra 2009;Kinder 2012;Wagner 2019], e.g., in malware analysis where malware tend to conceal their behavior using obfuscation techniques [Campion et al. 2021;Dalla Preda et al. 2015;Moser et al. 2007;You and Yim 2010].Being able to discover program variables that behave monotonically grants us the possibility to precisely analyze them and, thus, gain a better understanding of the malware's behavior.
As future work, we plan to investigate the relation between the recently introduced notion of partial completeness [Campion et al. 2022a[Campion et al. ,b, 2023] ] and monotonocity.Allowing a limited nonmonotone behavior of a program over certain variables may be related to a weakening of the notion of complete-analyzability, thus admitting a partial completeness of the BCA.Moreover, it could be interesting to formalize a proof system able to underapproximate the set of complete-analyzable programs for an abstraction and a set of inputs without passing through monotonicity, as done for, e.g., the local completeness [Ascari et al. 2023;Bruni et al. 2023;Milanese and Ranzato 2022].
The properties of boundedness and convexity, both depending on the program under inspection, would require dedicated analysis.Although our current work primarily centers on the monotonicity property, we recognize the importance of exploring these aspects in future investigations.The boundness analysis involves the study on how to nd minimum/maximum points over a set of inputs and to check termination over them.Convexity may require another analysis in the style of Section 3 even though there are well known abstract domains composed by only convex properties that trivially satisfy convexity (e.g., Intervals).
Although Theorem 4.10 considers non-relational abstractions only, we may think of partitioning the set of program variables in blocks containing monotone variables only and therefore obtaining a "weakly relational" abstract domain involving relations among only the variables in these blocks.This could potentially be related to the methods used for decomposing relational numerical abstract shapes, as considered in [Cousot et al. 2019;Singh et al. 2018].
In our current development, which does not involve data structures like arrays or pointers, the main source of imprecision in the monotonicity veri er lies within branches and loops: analyzing the validity of the predicates Boundary and Limit might be complex, and, additionally, they both may turn false even if the program is -monotone.This may depend on some factors such as the presence of non-linear Boolean guards in if-statements and loops as we have not identi ed an e cient method to handle them without executing the program under analysis.Further investigation is required to ne-tune the veri er's precision in this direction.
There is a considerable amount of research on algorithmic problems for the generation of ranking functions (e.g., see [Almagor et al. 2021;Ben-Amram et al. 2019;Ben-Amram and Genaim 2014]) for proving loop termination which is also strongly connected with program monotonicity.For instance, it would be interesting to modify the proposed proof system in order to consider a notion of strictmonotonicity (namely, either -increasing or -decreasing).Suppose the guard of the loop has the form ∈ + ⋗ and Var ( ) ⊆ .In such case, when the loop body is proven to be -decreasing at and every input in has at least a comparable state in (formally ∀ ∈ .∃ ′ ∈ .< ′ ∨ > ′ ), it can be regarded as evidence for the existence of a ranking function among program states , thus a su cient condition to establish termination.Moreover, rather than con ning monotonicity to integer numbers, it would be interesting to extend its de nition to ordinals, enabling the discovery of ordinal-based ranking functions for conditional termination proofs.[Urban and Miné 2014a,b].
def = {[ , ] | , ∈ I * , ≤ } ∪ {⊥ Int } endowed with the standard ordering ≤ Int induced by the interval containment gives rise to a complete lattice, where ⊥ Int is the bottom element and ⊤ Int def = [−∞, +∞] is the top element.We have that Int ∈ Abs(℘(I)).Consider the function min : ℘(I) → I * de ned as min( ) def = if there exists ∈ such that for all ∈ ≤ , while min( ) def = −∞ otherwise, and the function max : ℘(I) → I * dually de ned.The abstraction map Int : ℘(I) → Int is de ned by:

Fig. 4 .⋗
Fig. 4. Representation of the disjunction of the Boolean guard + − 2 ≤ 0, in red, and 2 + − 3 ≤ 0, in blue, of Example 3.5.All states satisfying the guard are in the green region, while the white area contains the states that do not satisfy the Boolean guard.

Fig. 7 .
Fig. 7. On the le , the 2-dimensional representation of = { , , , } (blue points) and Zone ( Zone ( )) which adds (the red point).On the right, the monotone transformation of where the region outlined by the blue dashed line represents Zone ( Zone ()), while the red dashed line corresponds to the region added by Zone ( Zone ( )).
Abs(C) means that A is an abstract domain of C de ned by some GI which is left unspeci ed.We say that a concrete element ∈ C is representable (or expressible) in A whenever A ( A ( )) = .If we consider two abstract domainsA 1 , A 2 ∈ Abs(C) then A 1 is a more precise abstraction than A 2 , or, equivalently, A 2 abstracts A 1 , if and only if for all ∈ C, A 1 ( A 1 ( )) ≤ C A 2 ( A 2 ( )), and it is denoted by A 1 ≤ Abs( C) A 2 .An abstract domain A ∈ Abs(C) is said to be trivial when A = C, namely, it is isomorphic to the concrete domain C (i.e., A • A is the identity function).
6] even P⊓I P⊓I ({2, 5}) = P⊓I ({2, 3, 4, 6}) = [2, 6] we can conclude that P ⊓ I is not { }-convex at {2, 5}, since [2, 6] even has many holes, namely, all the odd numbers in[2, 6]. is monotone over P⊓I ( P⊓I ({2, 5})) but So far we have exclusively focused on non-relational abstractions.A follow-up question could be whether it is possible to extend the result of Theorem 4.10 to relational abstractions able to infer a ne inequalities.These include, e.g., Zones and Octagons abstract domains Zone, Oct ∈ Abs(℘(I )) which are able to express constraints with two variables: − ≤ for Zone, while ± ± ≤ for Oct with ∈ I.