Formal Proof of SCHUR Conjugate Function

F ormal Pro of of SCHUR Conjugate F unction ? ?? F ranc k Butelle 1 , Floren t Hiv ert 2 , Micaela Ma y ero 1 , 3 , and F r ´ ed ´ eric T oumazet 4 1 LIPN UM R 7030, Univ ersit´ e P aris 13, Villetaneuse, F-93430 2 LITIS EA 4108, Universit ´ e de Rouen, Saint-Etienne-du-Rouvra y , F-76801 3 LIP , INRIA Grenoble – Rhˆ one-Alp es, UMR 5668, UCBL, ENS Ly on, Lyon, F-69364 4 LIGM UMR 8049, Universit ´ e de Marne-la-V all´ ee, Champs sur Marne, F-77454 Abstract. The main goal of our w ork is to formally prov e the cor- rectness of the key commands of the SCHUR soft w are, an in teractiv e program for calculating with characters of Lie groups and symmetric functions. The core of the computations relies on enumeration and ma- nipulation of com binatorial structures. As a first ”proof of concept”, w e presen t a formal pro of of the conjugate function, written in C. This function computes the conjugate of an in teger partition. T o formally pro ve this program, we use the F rama-C softw are. It allows us to an- notate C functions and to generate proof obligations, whic h are pro v ed using several automated theorem prov ers. In this pap er, w e also draw on metho dology , discussing on ho w to formally pro v e this kind of program. 1 In tro duction SCHUR [1] is an interactiv e softw are for calculating prop erties of Lie groups and symmetric functions [2]. It is used in research by combinatorists, physicists, theoretical chemists [3] as well as for educational purp ose as a learning tool for studen ts in algebraic combinatorics. One of its main uses is to state conjectures on com binatorial ob jects. F or such use, it is important to ha v e some confidence in the results pro duced b y SCHUR. Un til now, the method used to get some confidence in the results has mostly b een based on just one example for eac h command. The computation of other examples is complex due to the well kno wn combi- natorial explosion, especially when using algorithms asso ciated to the symmetric group, see section 2.1. Unfortunately , the com binatorial explosion as w ell as com- puting time forbid test generation or verification tec hniques (mo del c hec king). Therefore, in this pap er, w e focus on formal pro of of the existing program. With the aim of verifying the whole softw are, we start with proving the correctness of its fundamentals bricks. The main combinatorial ob ject used in SCHUR is in teger partition. The first non-trivial op eration on in teger partitions is the conjugate. Moreo v er, conjugate function is necessary for more than half of the 240 interactiv e commands of SCHUR. F rom this p oin t of view, we can sa y that conjugate is a critical function of SCHUR. ? This research is supported b y the PEPS-CNRS pro ject CerBISS. ?? The final publication of this pap er is a v ailable at www.springerlink.com The v ery first work consists in isolating (see 4.3) the co de of this function from the program. Next, w e chose to use the most popular to ol of program proof comm unit y’s F rama-C [4] successor of Caduceus. F rama-C is a plug-in system. In order to prov e programs, w e used Jessie [5], the deductiv e v erification plug-in of C programs annotated with A CSL [6]. The generated verification conditions can be submitted to external automatic prov ers, and for more complex situations, to in teractiv e theorem pro v ers as well (see section 2.2). After a short presen tation of softw are to ols and theoretical concepts, w e will presen t the formal proof of a program. Finally , after discussing difficulties and mistak es encountered along the wa y , we will prop ose a metho dology to prov e suc h a soft w are, and finally discuss future work. 2 Presen tation of the Softw are Used 2.1 The SCHUR Softw are SCHUR is an interactiv e softw are for calculating prop erties of Lie groups and symmetric functions. A Symmetric F unction is a function which is symmetric, or inv ariant, under an y p erm utation of its v ariables. F or example f ( x 1 , x 2 , x 3 ) = x 1 + x 2 + x 3 is a symmetric function. SCHUR has originally written by Prof. Brian G. Wybourne in Pascal lan- guage. Then it was translated in to C by an automatic program making it quite difficult to read. There are almost no comments in the code, the co de is more than 50,000 lines long with many global v ariables. Lo cal v ariables ha ve names suc h as W 52 and so on. After the death of Prof. Wyb ourne in Nov ember 2003, some p eople felt that his program should b e maintained, and if p ossible enhanced, with a view to making it freely a v ailable to the mathematics and physics research comm unit y . No w ada ys, it is open source under the GPL license and includes more than 240 commands. The co de still includes v ery few commen ts. Some mistak es ha ve b een corrected but some interactiv e commands are so intricate that it is difficult to hav e more than a few examples to chec k them against and most p eople do not ev en kno w if the result is correct or not. This is wh y w e started to work on this code. Firstly some of the commands in SCHUR are v ery w ell implemen ted (for example, pleth ysm is computed faster b y SCHUR than b y man y other com binatorial to olboxes). F ormally proving some k ey functions inside w ould also b e a ma jor adv ance for its researc h communit y . 2.2 The F rama-C Soft w are F rama-C [4] is an open source extensible platform dedicated to source code analy- sis of C soft ware. It is co-developed b y t w o F renc h public institutions: CEA–LIST (Soft w are Reliabilit y Lab oratory) and INRIA-Sacla y (ProV al pro ject). F rama-C is a plug-in system. In order to pro ve programs, we use Jessie [5], the deductive v erification plug-in of C programs annotated with ACSL [6]. It 2 uses in ternally the languages and to ols of the Why platform [7]. The Jessie plug-in uses Hoare-st yle [8] w eakest precondition computations to formally pro ve A CSL prop erties. The generated verification conditions (V C) can b e submitted to external automatic prov ers such as Simplify [9], Alt-Ergo [10], Z3 [11], CVC3 [12]. These automatic prov ers belong to SMT (Satisfiability Mo dulo Theories) solv ers. The SMT problem is a decision problem for logical formulas with re- sp ect to combinations of background theories expressed in classical first-order logic with equality . First-order logic is undecidable. Due to this high computa- tional difficult y , it is not possible to build a procedure that can solve arbitrary SMT problems. Therefore, most pro cedures focus on the more realistic goal of efficien tly solving problems that o ccur in practice. F or more complex situations, interactiv e theorem prov ers can b e used to establish the v alidity of V Cs, like Coq [13], PVS [14], Isab elle/HOL [15], etc. F or our purpose, w e used Co q (see section 4.2) since it is the one b est known to the authors. 3 The Conjugate F unction In this section, the basics of algebraic com binatorics are given so that the reader can understand what is actually prov ed. Interestingly in this field, though the in terpretation of what is actually computed can be of a very abstract algebraic lev el, the computation itself boils down most of the time to p ossibly in tricate but rather elemen tary manipulations. 3.1 Com binatorial and Algebraic Background: In teger Partitions A partition of a p ositiv e in teger n is a wa y of writing n as a sum of a non- increasing sequence of integers. F or example λ = (4 , 2 , 2 , 1) and µ = (2 , 1) are partitions of n = 9 and n 0 = 3 resp ectiv ely . W e write | λ | = n and | µ | = n 0 [16]. The F errers diagram F λ asso ciated to a partition λ = ( λ 1 , λ 2 , ..., λ p ) consists of | λ | = n b oxes, arranged in l ( λ ) = p left-justified rows of lengths λ 1 , λ 2 , ..., λ p . Rows in F λ are oriented do wnw ards (or up w ards for some au- thors). F λ is called the shap e of λ . Definition 1. The c onjugate of an inte ger p artition is the p artition asso ciate d to the diagonal symmetric of its shap e. F or example, for λ = (3 , 2 , 1 , 1 , 1), here is the F errers diagram F λ and the F errers diagram of the conjugate partition: 3 So the conjugate partition of (3 , 2 , 1 , 1 , 1) is (5 , 2 , 1). A semi-standard Y oung tableau of shap e λ is a num b ering of the b oxes of F λ with en tries from { 1 , 2 , ..., n } , weakly increasing across ro ws and strictly increasing down columns. A tableau is standard if and only if eac h entry app ears only once. Here is an example of shap e (4 , 2 , 2 , 1) tableau: 1 2 2 5 2 4 3 6 5 A symmetric function of a set of v ariables { x 1 , x 2 , . . . } is a function f ( x 1 , x 2 , . . . ) of those v ariables whic h is in v arian t under an y p erm utation of those v ariables (that is for example f ( x 1 , x 2 , . . . ) = f ( x 2 , x 1 , . . . )). This definition is usually restricted to p olynomial functions. The most important linear basis of symmetric function’s algebra is called the Sc h ur functions and they are com- binatorially defined as follows: for a giv en semi-standard Y oung tableau T of shap e λ , write x T the product of the x i for all i app earing in the tableau. Then s λ ( x ) = X T ∈ T ab( λ ) x T . (1) where T ab( λ ) is the set of all tableaux of shap e λ . W e will note s λ ( x ), s λ . F or example, consider the tableaux of shape (2 , 1) using just three v ariables x 1 , x 2 , x 3 : 1 1 2 1 1 3 2 2 3 1 2 3 1 3 2 1 2 2 1 3 3 2 3 3 The asso ciated Sc hur function is therefore: s (21) ( x 1 , x 2 , x 3 ) = x 2 1 x 2 + x 2 1 x 3 + x 2 2 x 3 + 2 x 1 x 2 x 3 + x 1 x 2 2 + x 1 x 2 3 + x 2 x 2 3 (2) th us: s (21) = s (21) ( x 1 , x 2 , x 3 ) + s (21) ( x 1 , x 2 , x 3 , x 4 ) + . . . Note that, with this com binatorial definition, the symmetry of s (21) ( x 1 , x 2 , x 3 ) is not exactly ob vious. W e need to recall some well-kno wn results in symmetric function theory: though Sch ur functions hav e historically been defined b y Jacobi [17], they w ere named in the honor of Sch ur who disco v ered their crucial role in the represen ta- tion theory of the symmetric group and the general linear group. Namely , after the disco very by F robenius that the irreducible representation of the symmetric groups are indexed b y in teger partitions, Sch ur sho w ed that those functions can b e in terpreted as c haracters of those irreducible represen tation, and b y Sch ur- W eyl dualit y characters of Lie groups and Lie algebras. Notably we obtain the represen tation of the general linear groups ( GL n ) and unitary groups ( U n ) [18] from the symmetric group representations. In this setting, the conjugate of the 4 partition essentially enco des the tensor pro duct of a representation by the sign represen tation. F urther w ork b y Sch ur-Littlewoo d inv olve infinite sum of Sc hur functions asso ciated to partitions [19], whose conjugates ha ve a particular form. In partic- ular, these series are used to obtain symplectic ( S p 2 n ) and orthogonal character groups ( O n ) (symmetric and orthogonal Sc h ur functions) from standard Sch ur functions [20]. One particularly important and difficult computational problem here is pleth ysm (see SCHUR reference man ual [1] and [2]). It is the analogue in sym- metric functions of the substitution of polynomial inside another polynomial f ( x ) 7→ f ( g ( x )). It is called plethysm b ecause b y some com binatorial explosion, it inv olves very quic kly a lot (a plethora) of terms, making it something very difficult to compute efficiently . F or example, s (21) ( s (21) ), the first example with non trivial partitions in the input is already v ery hard to compute b y hand. First w e can regard s (21) as a function in as man y monomial as in (2): s (21) ( s (21) )( x 1 , x 2 , x 3 ) = s (21) ( x 2 1 x 2 , x 2 1 x 3 , x 2 2 x 3 , x 1 x 2 x 3 , x 1 x 2 x 3 , x 1 x 2 2 , x 1 x 2 3 , x 2 x 2 3 ) it can b e sho wn that the following holds: s (21) ( s (21) ) = s (22221) + s (321111) + 2 s (32211) + s (3222) + s (33111) + 3 s (3321) + 2 s (42111) + 3 s (4221) + 3 s (4311) + 3 s (432) + s (441) + s (51111) + 2 s (5211) + s (522) + 2 s (531) + s (54) + s (621) 3.2 Computation in Algebraic Combinatorics Basically , the arc hitecture of a soft ware for computing in algebraic com binatorics is comp osed of t wo parts: – a computer algebra k ernel dealing with the bo okk eeping of expressions and linear combinations (parsing, prin ting, collecting, Gaussian and Gro ebner elimination algorithm. . . ); – a very large bunch of small combinatorial functions which en umerate and manipulate the com binatorial data structures. In algebraic combinatorics soft ware, for each basic combinatorial structure suc h as p erm utations or partitions, there are t ypically 50-200 differen t functions. Con- jugating a partition is a very go od example of what those many functions do, that is surgery on lists of in tegers or lists of lists of in tegers or more adv anced recursiv e structures like trees. . . In a basic computation, most of the time is sp en t mapping or iterating those functions on some sets of ob jects. But due to com binatorial explosion those sets can b e v ery large so these functions must be v ery w ell optimized. 3.3 Prop erties The definition of conjugate (diagonal symmetric of its partition shape) is easy to understand but ma y conduct to naiv e implemen tations that may b e inefficient. 5 Let us supp ose that we represen t an in teger partition by an integer array starting from 1. F or example λ = (3 , 2 , 1 , 1 , 1) giv es t [1] = 3, t [2] = 2,... t [ l ( λ )] = 1. Recall that t [ i ] is non-increasing, that is t [ i + 1] ≤ t [ i ]. One w ay to compute the conjugate is to coun t b o xes: in our previous example the first column of λ had 4 b o xes, the second had 3 etc. Therefore, to compute the n um b er of b o xes in a column j we need to kno w ho w man y lines are longer than j . As a consequence, if t c is the arra y representing the conjugate, the following form ula giv es the v alue of the entries of the conjugate: t c [ j ] = |{ i | 1 ≤ i ≤ l ( λ ) ∧ t [ i ] ≥ j }| . Note that t c [ j ] = 0 if j > t [1], so the previous expression must be computed only from j = 1 to j = t [1]. This last prop erty will b e one of our predicates used to c hec k the correctness of lo op in v ariants. 3.4 SCHUR Implemen tation Here follo ws the code of the conjugate function extracted from the SCHUR soft w are. W e expanded type definitions (C “structs” and “typedefs”) from the original co de just to simplify the work of F rama-C and to make this part of co de indep enden t from the rest of the SCHUR soft ware (getting rid of global v ariables and so on). #define MAX 100 void conjgte (int A[MAX], int B[MAX]) { int i, partc = 1, edge = 0; while (A[partc] != 0) { edge = A[partc]; do partc = partc + 1; while (A[partc] == edge); for (i = A[partc] + 1; i <= edge; i++) B[i] = partc - 1; } } Note that this implemen tation is not naiv e (and not so easy to understand) but its time complexit y is optimal (linear in the length of the partition). The algorithm is based on lo oking for the set of descen ts of the partition 5 . The do–while lo op follows a “flat” p ortion of the partition ( t [ i ] = t [ i − 1]) until a descen t is found. Next the for–lo op assigns the v alues of the B arra y according to the flat p ortion. The follo wing figure clarifies this: w e ha ve denoted partc 1 the v alue of partc at the en trance of while lo op. partc 2 is the v alue of partc after 5 A descent is suc h that t [ i ] < t [ i − 1] 6 the do–while lo op. F or clarity’s sak e w e supp osed A [ partc 2 ]+1 to b e different from A [ partc 1 ]. If we count boxes column by column to construct arra y B , it is clear that B [ i ]= partc 2 -1 for all A [ partc 2 ]+1 ≤ i ≤ A [ partc 1 ]= edge . 1 ... A [ partc 2 ] A [ partc 2 ]+1 ... A [ partc 1 ] ... A [1] ↓ ↓ ↓ ↓ ↓ 1 → ... ... ... . . . . . . . . . . . . . . . partc 1 → ... ... . . . . . . . . . . . . . . . partc 1 +n → ... ... partc 2 → ... . . . . . . . . . 4 The F ormal Pro of of the Conjugate F unction 4.1 Annotations In the follo wing paragraphs we present the annotations added to the code. Note that this is the only additions made to it. First w e ha ve to specify the mo del of in tegers w e w an t to deal with: #pragma JessieIntegerModel(strict) This means that int types are mo deled by integers with appropriate b ounds, and for each arithmetic op eration, it is mandatory to show that no o v erflo w o ccurs. Next, we ha ve to express in first-order logic what an integer partition (stored in an arra y) is: #define MAX 100 /*@ predicate is_partition{L}(int t[]) = (\forall integer i; 1 <= i < MAX ==> 0 <= t[i] < (MAX-1)) && (\forall integer i,j; 1 <= i <=j < MAX ==> t[j] <= t[i]) && t[MAX-1]==0; */ Note that annotations are co ded in the C commen ts, starting with a @ . The {L} term is the con text (pre, p ost, etc.), we won’t detail it here, see [5, 6] for details. 7 The data structure (array of in tegers) comes from the w ay the SCHUR soft- w are represents integer partitions. 0 is used as a mark of end of arra y , just lik e c haracter strings in C. The MAX v alue comes from the original source code as w ell. The first line of the predicate is_partition expresses that w e are able to compute the conjugate (if at least one elemen t is greater than or equal to MAX- 1, the conjugate will no b e able to b e stored in an array of size MAX-1 with the last element fixed to 0). F rom the source co de it is expressed b y an external simple test on t[1] , but expressing it like that simplifies automatic pro v ers job. The second line of the predicate defines the non-increasing order. The follo wing predicate is needed to express ho w we count blo cs to compute the conjugate. It may be read as z equals the num b er of elemen ts of partition t , whose indexes are included in { 1 , .., j − 1 } and whose v alues are greater than or equal to k . It is theoretically p ossible to express it as an axiomatic theory , a kind of function, but automatic prov ers we use make a better use of predicates. Note that we need to explicit the z = 0 case, in order to b e able to prov e the global p ost-condition is_conjugate(A,B) . /*@ predicate countIfSup{L}(int t[],integer j,integer k,integer z)= is_partition{L}(t) && 1<= j <= MAX && 1<= k < MAX && ((1<=z t[i]>= k) || (z==0 && \forall integer i ; 1<=i t[i] countIfSup(t1,MAX,k,t2[k]); */ Finally , here is the function. First w e ha v e to giv e precise requiremen ts on the inputs. F or example, ( \valid(A+ (1..(MAX-1))) means that memory has b een allo cated so arra y indexes from 1 to MAX-1 are allo wed). F rom the original co de, the B arra y is supp osed to be initialized with zeros b efore calling the function. This is translated into a requires directive. Next, we sp ecify which memory elemen ts are mo dified b y the function ( assigns ). This is used for safety proofs. In the end, the output is correct if the p ost-condition ( ensures ) is met. /*@ requires \valid(A+ (1..(MAX-1))); requires \valid(B+ (1..(MAX-1))); requires is_partition(A); requires \forall integer k; 1<=k B[k]== 0; assigns B[1..A[1]]; ensures is_conjugate(A,B); */ 8 void conjgte (int A[MAX], int B[MAX]) { int i, partc=1, edge = 0 ; No w we hav e to define the loop v arian t and in v arian t for eac h lo op (to pro v e prop erties). The “lo op v ariant” must decrease, while remaining non negative, to b e able to pro v e termination. W e also use a “ ghost v ariable” to store the state of a v ariable b efore an y mo dification. /*@ loop variant MAX-partc; loop invariant 1<=partc countIfSup(A,MAX,k,B[k]); */ while (A[partc] != 0) { edge = A[partc]; /*@ ghost int old_partc = partc; */ /*@ loop variant MAX-partc; loop invariant old_partc<=partc ; loop invariant \forall integer k; old_partc<= k <= partc ==> A[k]==edge; loop invariant partc= A[partc]+1 && edge+1>=i ; loop invariant \forall integer k; A[partc]+1 <=k countIfSup(A,MAX,k,B[k]); loop assigns B[ (A[partc]+1)..edge]; */ for (i = A[partc] + 1; i <= edge; i++) B[i] = partc - 1; } } 9 Fig. 1. Graphical Interface: default b ehavior 4.2 Pro ofs The figures 1 to 3 are snapshots of gWhy (F rama-c graphical interface when using plugin Jessie). W e applied this to ol on the previous annotated code. The V erification Conditions (VC, also called pro of obligations) that hav e to b e pro v ed one by one (line b y line) appear to the left of each of the follo wing snapshots. In the upp er right part of the windo w, we can chec k at a glance what h yp otheses are known and what is to be pro v ed at the b ottom of it (under the line). No circularit y paradox is p ossible here, since the pro of of a VC can only rely on other V C higher in the control -flow graph of the function. In the low er righ t part of the window, the corresp onding part of the annota- tion is highligh ted in the source co de with some lines before and after it. W e will no w fo cus on the VC part, to the left. W e can see (green) dots meaning that this prop erty has b een pro ved b y this pro v er. There is also (blue) rhom bus with a question mark inside (see assertion 13), indicating that this pro v er will not be able to to pro v e this property . Actually , this do es not mean that this V C is wrong, remember that these pro v ers use heuristics. Sometimes, y ou may see scissors meaning that the maxim um execution time has b een reached without pro ving the V C. Again, this do es not mean that the corresponding VC is wrong. Finally , at the top of a column a (green) c heck or (red, with a white cross inside) point is shown. The first one means that all prop erties hav e b een pro v ed by that pro v er. In fig.1, The (blue) arrow at the top of the CVC3 column means that it is still computing some unshown VC (greater than n umber 16). The last figure is the final part. The prov ers hav e work ed on the safety of the co de, that is to say , integer b ounds (ov erflow problems), p ointer referencing and termination. 10 Fig. 2. Graphical Interface contin ued As seen in section 4.1, the B arra y has to b e initialized with ze- ros b efore calling the function. This requirement has b een enlightened thanks to the annotations and to ols, in particular because without the line requires \forall integer k;1<=k B[k]==0 , the p ostcondition whic h states that B is a conjugate of A cannot b e pro ved. W e hav e also used Co q pro of assistan t. How ever, it not being essential to our presen t point, w e chose to liv e aside the detail of this pro cedure (see section 4.3). 4.3 Problems, Mistakes As usual when using formal pro of tools, there are several w a ys to formalize or to annotate programs. Choices made during at this stage are very imp ortan t for future pro ofs. F or example, declaring a function as an axiomatic theory or as a predicate will supp ose corresp onding pro ofs to b e different. W e can make a similar remark with data-t yp es used in programs. F or these reasons, using “goo d” annotations which allows automatic prov ers to pro ve v erification conditions (V C) successfully is a clev er wa y to go ab out it. When we deal with 40,000 lines of undo cumen ted code, another critical part of the work consists in “correctly” isolating the piece of code that we w an t to pro v e. The code can use global v ariables, initializations made b y other functions, or use in tricate data-t yp es and so on. In the follo wing paragraphs, these problems and associated mistak es are dis- cussed. Isolating a Part of Program. Generally speaking, the analyzed function m ust b e free of external calls. More precisely if a function is called from it, it has to b e incorporated in the co de (lik e macro expansion) or, at least, indep enden tly pro v ed. 11 Fig. 3. Graphical Interface: Safety Next, data types m ust be simplified. Ev en if F rama-C can cop e with simple structures, it is b etter to hav e a first pass on them (unions suppression, t yp edef expansion and so on). Ho w to Mak e Goo d Annotations? As previously explained, ACLS is a language whic h is used to annotate C programs. Annotating an existing program consists in choosing prop erties (comp ortment, results,...) that the user w an ts to b e “confirmed”, suc h as preconditions, lo op inv ariants, post conditions. In our case, for example, one of the most relev ant properties w e prov ed is that the r esult B is the c onjugate of the p artition A . This property is stated as a p ostcondition. As usual, there are sev eral w a ys to formalize annotations. P articularly when using external prov ers, a goo d metho d is to know ho w pro v ers work. Here, w e ha v e to remem ber that the automatic prov ers are SMT solvers (see section 2.2). As an example, w e can giv e the definition of countIfSup . In a first formal- ization we wrote it as an “axiomatization”. But due to another problem that w e will describ e in the next paragraph, w e needed to make some proofs in Coq whic h used countIfSup . Then, to mak e it easier for Co q, we decided to try to define it inductiv ely . Thanks to this other definition, some conditions were automati- cally prov ed by SMT solv ers. This example sho ws how important formalization c hoices can b e. In the next paragraph, w e will explain and illustrate ho w Co q allo wed us to correct some errors in our annotations. 12 Wh y Co q? Once annotations are completed, the metho d consists in using automatic prov ers (using gWh y for example). As previously explained, if all pro of obligations are pro ved b y at least one prov er, the work can b e considered as finished. But, if one or more pro of obligations is/are still unprov ed, several approac hes are p ossible: the first one consists in v erifying that annotations are “sufficien t”, that is to sa y a precondition or a lo op in v arian t is not missing. Another approach, when the user supp ose that his annotations are correct, is to use an external non automatic prov er to try to prov e pro of obligations that hav e not b een v erified previously . In our case, we used the interactiv e theorem prov er Co q t wice. The first time w as b ecause a p ostcondition had not been pro v ed b y SMT pro vers. When w e b e- gan Co q pro of, we disco v ered that the definition of countIfSup was incomplete: the second part of the “ || ” (logical or) w as missing. The second time we used Co q w as to prov e a loop inv ariant. Similarly , w e detected another incompleteness in countIfSup definition ( j < M AX instead of j ≤ M AX ). Proof assistants are well adapted to detect this kind of problems. Indeed, building formal pro ofs manually , a user can easily see whic h hypotheses are necessary . After ha ving corrected and replaced the “axiomatization” of countIfSup by a predicate, all pro of obligations hav e b een prov ed by at least one automatic pro v er. Note that the new definition allo w ed us to remov e from the annotations one additional lemma whic h, at first, app eared necessary . Other Vicissitudes. Among the main encoun tered difficulties, w e can men tion the confidence in the prov ers we used. In our case, one of the versions of CV C3 w as faulty and prov ed all V C correct, even when they w ere false. F or this reason w e decided to consider that a pro of obligation was pro ved when at least tw o automatic prov ers succeed on proving it. It is the case for all our obligations except one (V C # 23 is only pro ved b y Simplify). The pro of of V C # 23 is in progress using Co q. 5 Conclusion and F uture W ork W e hav e isolated and formally prov ed one of the k ey commands of the SCHUR soft w are. This w ork reinforced us in the idea of formally proving chosen parts of soft w are of the same kind, comp osed of 40,000 lines of undocumented code. Thanks to this approach, we ha v e fo cused on critical p oin ts (such as par- ticular initializations of arra ys and appropriate b ounds) from the original co de and b y extension, we hav e understoo d the progression axis of the metho dology . In particular, it is b etter to know ho w SMT automatic prov ers w ork to try to mak e a “go od” annotation so that obligation pro ofs will be more easily pro ved b y them. In the methodology , non automatic external prov ers lik e Coq ma y b e used to refine annotations, and to prov e obligations when no automatic prov ers succeed. 13 The conjugate function is a basic brick of com binatorics. This giv e us persp ec- tiv e to prov e other functions. Therefore, as a future w ork, the second step is to pro v e algorithms relying on exhaustive enumeration algorithm, such as compu- tation of Littlewoo d-Ric hardson co efficients, Kosk as num b ers, Kosk as matrices, represen tation m ultiplicit y in tensor pro duct decompositions, etc. The final ob jective will be to build prov ed libraries usable for scien tific com- m unit y . References 1. Butelle, F., King, R., T oumazet, F.: SCHUR, an in teractive program for calculating prop erties of Lie groups and symmetric functions, http://sc hur.sourceforge.net. Release 6.06. 2. MacDonald, I.G.: Symmetric F unctions and Hall P olynomials. Clarendon Press, Oxford Universit y Press (New Y ork) (1979) 2nd edition in 1998. 3. King, R.C., Bylicki, M., Karwo wski, J., eds.: Symmetry , Sp ectroscop y and SCHUR. Nicolaus Cop ernicus Universit y Press (2006) 4. Correnson, L., Cuo q, P ., Puccetti, A., Signoles, J.: F rama-C User Man ual, Beryl- lium release, h ttp://frama-c.cea.fr 5. Marc h´ e, C., Mo y , Y.: Jessie T utorial, http://frama-c.cea.fr/jessie/jessie- tutorial.p df. Release 2.21. 6. Baudin, P ., Cuoq, P ., Filliˆ atre, J.C., March ´ e, C., Monate, B., Moy , Y., Prevosto, V.: A CSL: ANSI/ISO C Sp ecification Language, http://frama-c.cea.fr/do wnload/acsl- implemen tation-Beryllium-20090902.p df 7. Filliˆ atre, J.C., March ´ e, C., Moy , Y., Hubert, T., Rousset, N.: Wh y is a soft w are v erification platform, h ttp://wh y .lri.fr. Release 2.21. 8. Hoare, C.A.R.: An axiomatic basis for computer programming. Communications of the A CM 12 (10) (1969) 576–580 and 583 9. Detlefs, D., Nelson, G., Saxe, J.B.: Simplify: a theorem prov er for program chec k- ing. J. ACM 52 (3) (2005) 365–473 Release 1.5.4. 10. Conc hon, S., Contejean, E., Bob ot, F., Lescuyer, S.: Alt-Ergo is an automatic theorem prov er dedicated to program v erification, h ttp://ergo.lri.fr. Release 0.9. 11. Microsoft Researc h: Z3 An Efficien t SMT Solver, h ttp://research.microsoft.com/en-us/um/redmond/pro jects/z3. Release 2.4. 12. Barrett, C., Tinelli, C.: CVC3. In Damm, W., Hermanns, H., eds.: Pro ceedings of the 19 th In ternational Conference on Computer Aided V erification (CA V ’07). V olume 4590 of Lecture Notes in Computer Science., Springer-V erlag (July 2007) 298–302 http://cs.n yu.edu/acsys/cv c3 Release 20091011. 13. Bertot, Y., Cast´ eran, P .: Interactiv e Theorem Pro ving and Program Developmen t: Co q’Art: The Calculus of Inductive Constructions. EA TCS, T exts in Theoretical Computer Science. Springer V erlag (2004) 14. Shank ar, N., Owre, S., Rushb y , J.M., Stringer-Calvert, D.W.J.: PVS prov er guide, h ttp://pvs.csl.sri.com/doc/pvs-pro ver-guide.pdf 15. Nipk ow, T., P aulson, L.C., W enzel, M.: Isab elle/HOL — A Pro of Assistant for Higher-Order Logic. V olume 2283 of LNCS. Springer (2002) 16. Andrews, G.E.: The theory of partitions. Cam bridge Universit y Press (1984) 17. Jacobi, C.G.J.: De functionibus alternan tibus earumque divisione p er productum e differentiis elementorum conflatum. Journal f ¨ ur die reine und angewandte Math- ematik (Crelles Journal) 22 (1841) 360–371 Reprinted in Gesammelten W erke I I I, G. Reimer, Berlin, 1884. 14 18. Littlew o od, D.E.: The Theory of Group Characters. Oxford Universit y Press (1950) second edition. 19. Lascoux, A., Pragacz, P .: S-function series. J. Phys. A: Math. Gen. 21 (1988) 4105–4118 20. New ell, M.J.: On the representations of the orthogonal and symplectic groups. In: Pro c. Roy . Irish Acad., Section A: Mathematical and Ph ysical Sciences. V olume 54. (1951) 143–152 15