We systematically develop a functional program that solves the countdown problem, a numbers game in which the aim is to construct arithmetic expressions satisfying certain constraints.  Starting from a formal specification of the problem, we present a simple but inefficient program that solves the problem, and prove that this program is correct.  We then use program fusion to calculate an equivalent but more efficient program, which is then further improved by exploiting arithmetic properties

Hutton, Graham

English

Name not available

The Countdown Problem

Nottingham eTheses

Hutton, Graham (2002) The Countdown Problem. Journal of Functional Programming, 12 (6). pp. 609-616. Access from the University of Nottingham repository: http://eprints.nottingham.ac.uk/226/1/countdown.pdfCopyright and reuse: The Nottingham ePrints service makes this work by researchers of the University of Nottingham available open access under the following conditions.This article is made available under the University of Nottingham End User licence and may be reused according to the conditions of the licence.  For more details see: http://eprints.nottingham.ac.uk/end_user_agreement.pdfA note on versions: The version presented here may differ from the published version or from the version of record. If you wish to cite this item you are advised to consult the publisher’s version. Please see the repository url above for details on accessing the published version and note that access may require a subscription.For more information, please contact eprints@nottingham.ac.ukTo appear in the Journal of Functional Programming 1FUNCTIONAL PEARLSThe countdown problemGRAHAM HUTTONSchool of Computer Science and ITUniversity of Nottingham, Nottingham, UKwww.cs.nott.ac.uk/~gmhAbstractWe systematically develop a functional program that solves the countdown problem, anumbers game in which the aim is to construct arithmetic expressions satisfying certainconstraints. Starting from a formal specification of the problem, we present a simple butinefficient program that solves the problem, and prove that this program is correct. Wethen use program fusion to calculate an equivalent but more efficient program, which isthen further improved by exploiting arithmetic properties.1 IntroductionCountdown is a popular quiz programme on British television that includes a num-bers game that we shall refer to as the countdown problem. The essence of theproblem is as follows: given a sequence of source numbers and a single target num-ber, attempt to construct an arithmetic expression using each of the source numbersat most once, and such that the result of evaluating the expression is the targetnumber. The given numbers are restricted to being non-zero naturals, as are theintermediate results during evaluation of the expression, which can otherwise befreely constructed using addition, subtraction, multiplication and division.For example, given the sequence of source numbers [1, 3, 7, 10, 25, 50] and thetarget number 765, the expression (1 + 50) ∗ (25− 10) solves the problem. In fact,for this example there are 780 possible solutions. On the other hand, changing thetarget number to 831 gives a problem that has no solutions.In the television version of the countdown problem there are always six sourcenumbers selected from the sequence [1 . . 10, 1 . . 10, 25, 50, 75, 100], the target num-ber is randomly chosen from the range 100 . . 999, approximate solutions are ac-ceptable, and there is a time limit of 30 seconds. We abstract from these additionalpragmatic concerns. Note, however, that we do not abstract from the non-zero nat-urals to a richer numeric domain such as the integers or the rationals, as this wouldfundamentally change the computational complexity of the problem.In this article we systematically develop a Haskell (Peyton Jones, 2001) programthat solves the countdown problem. Starting from a formal specification of theproblem, we present a brute force implementation that generates and evaluates all2 G. Huttonpossible expressions over the source numbers, and prove that this program is correct.We then calculate an equivalent but more efficient program by fusing togetherthe generation and evaluation phases, and finally make a further improvement byexploiting arithmetic properties to reduce the search and solution spaces.2 Formally specifying the problemWe start by defining a type Op of arithmetic operators, together with a predicatevalid that decides if applying an operator to two non-zero naturals gives a non-zeronatural, and a function apply that actually performs the application:data Op = Add | Sub | Mul | Divvalid :: Op → Int → Int → Boolvalid Add = Truevalid Sub x y = x > yvalid Mul = Truevalid Div x y = x ‘mod ‘ y == 0apply :: Op → Int → Int → Intapply Add x y = x + yapply Sub x y = x − yapply Mul x y = x ∗ yapply Div x y = x ‘div ‘ yWe now define a type Expr of arithmetic expressions, together with a functionvalues that returns the list of values in an expression, and a function eval thatreturns the overall value of an expression, provided that it is a non-zero natural:data Expr = Val Int | App Op Expr Exprvalues :: Expr → [Int ]values (Val n) = [n ]values (App l r) = values l ++ values reval :: Expr → [Int ]eval (Val n) = [n | n > 0]eval (App o l r) = [apply o x y | x ← eval l , y ← eval r , valid o x y ]Note that failure within eval is handled by returning a list of results, with theconvention that a singleton list denotes success, and the empty list denotes failure.Such failure could also be handled using the Maybe monad and the do notation(Spivey, 1990; Launchbury, 1993), but limiting the use of monads in our programsto the list monad and the comprehension notation leads to simpler proofs.Using the combinatorial functions subs and perms that return the lists of allsubsequences and permutations of a list (Bird & Wadler, 1988), we define a functionsubbags that returns the list of all permutations of all subsequences of a list:subbags :: [a ] → [ [a ] ]subbags xs = [zs | ys ← subs xs, zs ← perms ys ]Functional pearls 3Finally, we can now define a predicate solution that formally specifies what itmeans to solve an instance of the countdown problem:solution :: Expr → [Int ]→ Int → Boolsolution e ns n = elem (values e) (subbags ns) ∧ eval e == [n ]That is, an expression e is a solution for a list of source numbers ns and a targetnumber n if the list of values in the expression is a subbag of the source numbers (thelibrary function elem decides if a value is an element of a list) and the expressionsuccessfully evaluates to give the target number.3 Brute force implementationIn this section we present a program that solves countdown problems by the bruteforce approach of generating and evaluating all possible expressions over the sourcenumbers. We start by defining a function split that takes a list and returns the listof all pairs of lists that append to give the original list:split :: [a ] → [([a ], [a ])]split [ ] = [([ ], [ ])]split (x : xs) = ([ ], x : xs) : [(x : ls , rs) | (ls , rs)← split xs ]For example, split [1, 2] returns the list [([ ], [1, 2]), ([1], [2]), ([1, 2], [ ])]. In turn, wedefine a function nesplit that only returns those splittings of a list for which neithercomponent is empty (the library function filter selects the elements of a list thatsatisfy a predicate, while null decides if a list is empty or not):nesplit :: [a ]→ [([a ], [a ])]nesplit = filter ne ◦ splitne :: ([a ], [b ]) → Boolne (xs , ys) = ¬ (null xs ∨ null ys)Other definitions for split and nesplit are possible (for example, using the libraryfunctions zip, inits and tails), but the above definitions lead to simpler proofs.Using nesplit we can now define the key function exprs , which returns the list ofall expressions whose values are precisely a given list of numbers:exprs :: [Int ]→ [Expr ]exprs [ ] = [ ]exprs [n ] = [Val n ]exprs ns = [e | (ls , rs) ← nesplit ns , l ← exprs ls ,r ← exprs rs , e ← combine l r ]That is, for the empty list of numbers there are no expressions, while for a singlenumber there is a single expression comprising that number. Otherwise, we calculateall non-empty splittings of the list, recursively calculate the expressions for eachof these lists, and then combine each pair of expressions using each of the four4 G. Huttonarithmetic operators by means of an auxiliary function defined as follows:combine :: Expr → Expr → [Expr ]combine l r = [App o l r | o ← ops ]ops :: [Op ]ops = [Add ,Sub,Mul ,Div ]Finally, we can now define a function solutions that returns the list of all expres-sions that solve an instance of the countdown problem by generating all possibleexpressions over each subbag of the source numbers, and then selecting those ex-pressions that successfully evaluate to give the target number:solutions :: [Int ]→ Int → [Expr ]solutions ns n = [e | ns ′ ← subbags ns, e ← exprs ns ′, eval e == [n ] ]For example, using the Glasgow Haskell Compiler (version 5.00.2) on a 1GHzPentium-III laptop, solutions [1, 3, 7, 10, 25, 50] 765 returns the first solution in0.89 seconds and all 780 solutions in 113.74 seconds, while if the target number ischanged to 831 then the empty list of solutions is returned in 104.10 seconds.4 Proof of correctnessIn this section we prove that our brute force implementation is correct with respectto our formal specification of the problem. For the purposes of our proofs, all listsare assumed to be finite. We start by showing the sense in which the auxiliaryfunction split is an inverse to the append operator (++):Lemma 1: elem (xs, ys) (split zs) ⇔ xs ++ ys == zsProof: by induction on zsOur second result states that a value is an element of a filtered list precisely whenit is an element of the original list and satisfies the predicate:Lemma 2: if p is total (never returns ⊥) thenelem x (filter p xs) ⇔ elem x xs ∧ p xProof: by induction on xsUsing the two results above, we can now show by simple equational reasoningthat the function nesplit is an inverse to (++) for non-empty lists:Lemma 3: elem (xs, ys) (nesplit zs) ⇔ xs ++ ys == zs ∧ ne (xs , ys)Proof:elem (xs , ys) (nesplit zs)⇔ { definition of nesplit }elem (xs , ys) (filter ne (split zs))⇔ { Lemma 2, ne is total }elem (xs , ys) (split zs) ∧ ne (xs , ys)Functional pearls 5⇔ { Lemma 1 }xs ++ ys == zs ∧ ne (xs, ys)In turn, this result can be used to show that the function nesplit returns pairs oflists whose lengths are strictly shorter than the original list:Lemma 4: if elem (xs, ys) (nesplit zs) thenlength xs < length zs ∧ length ys < length zsProof: by equational reasoning, using Lemma 3Using the previous two results we can now establish the key lemma, which statesthat the function exprs is an inverse to the function values:Lemma 5: elem e (exprs ns) ⇔ values e == nsProof: by induction on the length of ns, using Lemmas 3 and 4Finally, it is now straightforward to state and prove that our brute force imple-mentation is correct, in the sense that the function solutions returns the list of allexpressions that satisfy the predicate solution:Theorem 6: elem e (solutions ns n) ⇔ solution e ns nProof:elem e (solutions ns n)⇔ { definition of solutions }elem e [e ′ | ns ′ ← subbags ns , e ′ ← exprs ns ′, eval e ′ == [n ] ]⇔ { list comprehensions, Lemma 2 }elem e [e ′ | ns ′ ← subbags ns , e ′ ← exprs ns ] ∧ eval e == [n ]⇔ { simplification }or [elem e (exprs ns ′) | ns ′ ← subbags ns ] ∧ eval e == [n ]⇔ { Lemma 5 }or [values e == ns ′ | ns ′ ← subbags ns ] ∧ eval e == [n ]⇔ { definition of elem }elem (values e) (subbags ns) ∧ eval e == [n ]⇔ { definition of solution }solution e ns n5 Fusing generation and evaluationThe function solutions generates all possible expressions over the source numbers,but many of these expressions will typically be invalid (fail to evaluate), becausenon-zero naturals are not closed under subtraction and division. For example, thereare 33,665,406 possible expressions over the source numbers [1, 3, 7, 10, 25, 50], butonly 4,672,540 of these expressions are valid, which is just under 14%.In this section we calculate an equivalent but more efficient program by fusingtogether the generation and evaluation phases to give a new function results thatperforms both tasks simultaneously, thus allowing invalid expressions to be rejected6 G. Huttonat an earlier stage. We start by defining a type Result of valid expressions pairedwith their values, together with a specification for results:type Result = (Expr , Int)results :: [Int ]→ [Result ]results ns = [(e,n) | e ← exprs ns,n ← eval e ]Using this specification, we can now calculate an implementation for results byinduction on the length of ns. For the base cases length ns = 0 and length ns = 1,simple calculations show that results [ ] = [ ] and results [n ] = [(Val n,n) | n > 0].For the inductive case length ns > 1, we calculate as follows:results ns= { definition of results }[(e,n) | e ← exprs ns,n ← eval e ]= { definition of exprs , simplification }[(e,n) | (ls , rs) ← nesplit ns, l ← exprs ls ,r ← exprs rs , e ← combine l r ,n ← eval e ]= { definition of combine, simplification }[(App o l r ,n) | (ls , rs)← nesplit ns, l ← exprs ls ,r ← exprs rs , o ← ops ,n ← eval (App o l r)]= { definition of eval , simplification }[(App o l r , apply o x y) | (ls , rs) ← nesplit ns , l ← exprs ls ,r ← exprs rs , o ← ops , x ← eval l , y ← eval r , valid o x y ]= { moving the x and y generators }[(App o l r , apply o x y) | (ls , rs) ← nesplit ns , l ← exprs ls ,x ← eval l , r ← exprs rs , y ← eval r , o ← ops , valid o x y ]= { induction hypothesis, Lemma 4 }[(App o l r , apply o x y) | (ls , rs) ← nesplit ns , (l , x )← results ls,(r , y) ← results rs, o ← ops , valid o x y ]= { simplification (see below) }[res | (ls , rs)← nesplit ns, lx ← results ls,ry ← results rs, res ← combine′ lx ry ]The final step above introduces an auxiliary function combine ′ that combines tworesults using each of the four arithmetic operators:combine ′ :: Result → Result → [Result ]combine ′ (l , x ) (r , y) = [(App o l r , apply o x y) | o ← ops , valid o x y ]In summary, we have calculated the following implementation for results:results :: [Int ]→ [Result ]results [ ] = [ ]results [n ] = [(Val n,n) | n > 0]results ns = [res | (ls , rs) ← nesplit ns , lx ← results ls,ry ← results rs, res ← combine′ lx ry ]Using results, we can now define a new function solutions ′ that returns the list ofFunctional pearls 7all expressions that solve an instance of the countdown problem by generating allpossible results over each subbag of the source numbers, and then selecting thoseexpressions whose value is the target number:solutions ′ :: [Int ]→ Int → [Expr ]solutions ′ ns n = [e | ns ′ ← subbags ns , (e,m) ← results ns ′,m == n ]It is now straightforward to show that our fused implementation is correct, in thesense that it has the same behaviour as our brute force version:Theorem 7: solutions ′ = solutionsProof:solutions ′ ns n= { definition of solutions ′ }[e | ns ′ ← subbags ns, (e,m) ← results ns ′,m == n ]= { specification of results, simplification }[e | ns ′ ← subbags ns, e ← exprs ns,m ← eval e,m == n ]= { simplification }[e | ns ′ ← subbags ns, e ← exprs ns, eval e == [n ] ]= { definition of solutions }solutions ns nIn terms of performance, solutions ′ [1, 3, 7, 10, 25, 50] 765 returns the first so-lution in 0.08 seconds (just over 10 times faster than solutions) and all solutionsin 5.76 seconds (almost 20 times faster), while if the target is changed to 831 theempty list is returned in 5.40 seconds (almost 20 times faster).6 Exploiting arithmetic propertiesThe language of arithmetic expressions is not a free algebra, but is subject toequational laws. For example, the equation x + y = y + x states that addition iscommutative, while x / 1 = x states that 1 is the right identity for division. In thissection we make a further improvement to our countdown program by exploitingsuch arithmetic properties to reduce the search and solution spaces.Recall the predicate valid that decides if applying an operator to two non-zeronaturals gives another non-zero natural. This predicate can be strengthened to takeaccount of the commutativity of addition and multiplication by requiring that theirarguments are in numerical order, and the identity properties of multiplication anddivision by requiring that the appropriate arguments are non-unitary:valid ′ :: Op → Int → Int → Boolvalid ′ Add x y = x  yvalid ′ Sub x y = x > yvalid ′ Mul x y = x = 1 ∧ y = 1 ∧ x  yvalid ′ Div x y = y = 1 ∧ x ‘mod ‘ y == 0Using this new predicate gives a new version of our formal specification of the8 G. Huttoncountdown problem. Although we do not have space to present the full details here,this new specification is sound with respect to our original specification, in the sensethat any expression that is a solution under the new version is also a solution underthe original. Conversely, the new specification is also complete up to equivalenceof expressions under the exploited arithmetic properties, in the sense that anyexpression that is a solution under the original specification can be rewritten togive an equivalent solution under the new version.Using valid ′ also gives a new version of our fused implementation, which we writeas solutions ′′. This new implementation requires no separate proof of correctnesswith respect to our new specification, because none of the proofs in previous sectionsdepend upon the definition of valid , and hence our previous correctness results stillhold under changes to this predicate. However, using solutions ′′ can considerably re-duce the search and solution spaces. For example, solutions ′′ [1, 3, 7, 10, 25, 50] 765only generates 245,644 valid expressions, of which 49 are solutions, which is justover 5% and 6% respectively of the numbers using solutions ′.As regards performance, solutions ′′ [1, 3, 7, 10, 25, 50] 765 now returns the firstsolution in 0.04 seconds (twice as fast as solutions ′) and all solutions in 0.86 seconds(almost 7 times faster), while for the target number 831 the empty list is returnedin 0.80 seconds (almost 7 times faster). More generally, given any source and targetnumbers from the television version of the countdown problem, our final programsolutions ′′ typically returns all solutions in under one second, and we have yet tofind such a problem for which it requires more than three seconds.7 Further workPossible directions for further work include the use of tabulation or memoisationto avoid repeated computations, exploiting additional arithmetic properties suchas associativity to further reduce the search and solution spaces, and generatingexpressions from the bottom-up rather than from the top-down.AcknowledgementsThanks to Richard Bird, Colin Runciman and Mike Spivey for useful comments,and to Ralf Hinze for the lhs2TeX system for typesetting Haskell code.ReferencesBird, Richard, & Wadler, Philip. (1988). An Introduction to Functional Programming.Prentice Hall.Launchbury, John. (1993). Lazy Imperative Programming. Proceedings of the ACM SIG-PLAN Workshop on State in Programming Languages.Peyton Jones, Simon. (2001). Haskell 98: A Non-strict, Purely Functional Language.Available from www.haskell.org.Spivey, Mike. (1990). A Functional Theory of Exceptions. Science of Computer Program-ming, 14(1), 25–43.

Repository@Nottingham

To appear in the Journal of Functional Programming 1FUNCTIONAL PEARLSThe countdown problemGRAHAM HUTTONSchool of Computer Science and ITUniversity of Nottingham, Nottingham, UKwww.cs.nott.ac.uk/~gmhAbstractWe systematically develop a functional program that solves the countdown problem, anumbers game in which the aim is to construct arithmetic expressions satisfying certainconstraints. Starting from a formal speciﬁcation of the problem, we present a simple butineﬃcient program that solves the problem, and prove that this program is correct. Wethen use program fusion to calculate an equivalent but more eﬃcient program, which isthen further improved by exploiting arithmetic properties.1 IntroductionCountdown is a popular quiz programme on British television that includes a num-bers game that we shall refer to as the countdown problem. The essence of theproblem is as follows: given a sequence of source numbers and a single target num-ber, attempt to construct an arithmetic expression using each of the source numbersat most once, and such that the result of evaluating the expression is the targetnumber. The given numbers are restricted to being non-zero naturals, as are theintermediate results during evaluation of the expression, which can otherwise befreely constructed using addition, subtraction, multiplication and division.For example, given the sequence of source numbers [1, 3, 7, 10, 25, 50] and thetarget number 765, the expression (1 + 50) ∗ (25− 10) solves the problem. In fact,for this example there are 780 possible solutions. On the other hand, changing thetarget number to 831 gives a problem that has no solutions.In the television version of the countdown problem there are always six sourcenumbers selected from the sequence [1 . . 10, 1 . . 10, 25, 50, 75, 100], the target num-ber is randomly chosen from the range 100 . . 999, approximate solutions are ac-ceptable, and there is a time limit of 30 seconds. We abstract from these additionalpragmatic concerns. Note, however, that we do not abstract from the non-zero nat-urals to a richer numeric domain such as the integers or the rationals, as this wouldfundamentally change the computational complexity of the problem.In this article we systematically develop a Haskell (Peyton Jones, 2001) programthat solves the countdown problem. Starting from a formal speciﬁcation of theproblem, we present a brute force implementation that generates and evaluates all2 G. Huttonpossible expressions over the source numbers, and prove that this program is correct.We then calculate an equivalent but more eﬃcient program by fusing togetherthe generation and evaluation phases, and ﬁnally make a further improvement byexploiting arithmetic properties to reduce the search and solution spaces.2 Formally specifying the problemWe start by deﬁning a type Op of arithmetic operators, together with a predicatevalid that decides if applying an operator to two non-zero naturals gives a non-zeronatural, and a function apply that actually performs the application:data Op = Add | Sub | Mul | Divvalid :: Op → Int → Int → Boolvalid Add = Truevalid Sub x y = x > yvalid Mul = Truevalid Div x y = x ‘mod ‘ y == 0apply :: Op → Int → Int → Intapply Add x y = x + yapply Sub x y = x − yapply Mul x y = x ∗ yapply Div x y = x ‘div ‘ yWe now deﬁne a type Expr of arithmetic expressions, together with a functionvalues that returns the list of values in an expression, and a function eval thatreturns the overall value of an expression, provided that it is a non-zero natural:data Expr = Val Int | App Op Expr Exprvalues :: Expr → [Int ]values (Val n) = [n ]values (App l r) = values l ++ values reval :: Expr → [Int ]eval (Val n) = [n | n > 0]eval (App o l r) = [apply o x y | x ← eval l , y ← eval r , valid o x y ]Note that failure within eval is handled by returning a list of results, with theconvention that a singleton list denotes success, and the empty list denotes failure.Such failure could also be handled using the Maybe monad and the do notation(Spivey, 1990; Launchbury, 1993), but limiting the use of monads in our programsto the list monad and the comprehension notation leads to simpler proofs.Using the combinatorial functions subs and perms that return the lists of allsubsequences and permutations of a list (Bird & Wadler, 1988), we deﬁne a functionsubbags that returns the list of all permutations of all subsequences of a list:subbags :: [a ]→ [ [a ] ]subbags xs = [zs | ys ← subs xs, zs ← perms ys ]Functional pearls 3Finally, we can now deﬁne a predicate solution that formally speciﬁes what itmeans to solve an instance of the countdown problem:solution :: Expr → [Int ]→ Int → Boolsolution e ns n = elem (values e) (subbags ns) ∧ eval e == [n ]That is, an expression e is a solution for a list of source numbers ns and a targetnumber n if the list of values in the expression is a subbag of the source numbers (thelibrary function elem decides if a value is an element of a list) and the expressionsuccessfully evaluates to give the target number.3 Brute force implementationIn this section we present a program that solves countdown problems by the bruteforce approach of generating and evaluating all possible expressions over the sourcenumbers. We start by deﬁning a function split that takes a list and returns the listof all pairs of lists that append to give the original list:split :: [a ]→ [([a ], [a ])]split [ ] = [([ ], [ ])]split (x : xs) = ([ ], x : xs) : [(x : ls , rs) | (ls , rs)← split xs ]For example, split [1, 2] returns the list [([ ], [1, 2]), ([1], [2]), ([1, 2], [ ])]. In turn, wedeﬁne a function nesplit that only returns those splittings of a list for which neithercomponent is empty (the library function filter selects the elements of a list thatsatisfy a predicate, while null decides if a list is empty or not):nesplit :: [a ]→ [([a ], [a ])]nesplit = filter ne ◦ splitne :: ([a ], [b ])→ Boolne (xs , ys) = ¬ (null xs ∨ null ys)Other deﬁnitions for split and nesplit are possible (for example, using the libraryfunctions zip, inits and tails), but the above deﬁnitions lead to simpler proofs.Using nesplit we can now deﬁne the key function exprs , which returns the list ofall expressions whose values are precisely a given list of numbers:exprs :: [Int ]→ [Expr ]exprs [ ] = [ ]exprs [n ] = [Val n ]exprs ns = [e | (ls , rs)← nesplit ns , l ← exprs ls ,r ← exprs rs , e ← combine l r ]That is, for the empty list of numbers there are no expressions, while for a singlenumber there is a single expression comprising that number. Otherwise, we calculateall non-empty splittings of the list, recursively calculate the expressions for eachof these lists, and then combine each pair of expressions using each of the four4 G. Huttonarithmetic operators by means of an auxiliary function deﬁned as follows:combine :: Expr → Expr → [Expr ]combine l r = [App o l r | o ← ops ]ops :: [Op ]ops = [Add ,Sub,Mul ,Div ]Finally, we can now deﬁne a function solutions that returns the list of all expres-sions that solve an instance of the countdown problem by generating all possibleexpressions over each subbag of the source numbers, and then selecting those ex-pressions that successfully evaluate to give the target number:solutions :: [Int ]→ Int → [Expr ]solutions ns n = [e | ns ′ ← subbags ns, e ← exprs ns ′, eval e == [n ] ]For example, using the Glasgow Haskell Compiler (version 5.00.2) on a 1GHzPentium-III laptop, solutions [1, 3, 7, 10, 25, 50] 765 returns the ﬁrst solution in0.89 seconds and all 780 solutions in 113.74 seconds, while if the target number ischanged to 831 then the empty list of solutions is returned in 104.10 seconds.4 Proof of correctnessIn this section we prove that our brute force implementation is correct with respectto our formal speciﬁcation of the problem. For the purposes of our proofs, all listsare assumed to be ﬁnite. We start by showing the sense in which the auxiliaryfunction split is an inverse to the append operator (++):Lemma 1: elem (xs, ys) (split zs) ⇔ xs ++ ys == zsProof: by induction on zsOur second result states that a value is an element of a ﬁltered list precisely whenit is an element of the original list and satisﬁes the predicate:Lemma 2: if p is total (never returns ⊥) thenelem x (filter p xs) ⇔ elem x xs ∧ p xProof: by induction on xsUsing the two results above, we can now show by simple equational reasoningthat the function nesplit is an inverse to (++) for non-empty lists:Lemma 3: elem (xs, ys) (nesplit zs) ⇔ xs ++ ys == zs ∧ ne (xs , ys)Proof:elem (xs , ys) (nesplit zs)⇔ { deﬁnition of nesplit }elem (xs , ys) (filter ne (split zs))⇔ { Lemma 2, ne is total }elem (xs , ys) (split zs) ∧ ne (xs , ys)Functional pearls 5⇔ { Lemma 1 }xs ++ ys == zs ∧ ne (xs, ys)In turn, this result can be used to show that the function nesplit returns pairs oflists whose lengths are strictly shorter than the original list:Lemma 4: if elem (xs, ys) (nesplit zs) thenlength xs < length zs ∧ length ys < length zsProof: by equational reasoning, using Lemma 3Using the previous two results we can now establish the key lemma, which statesthat the function exprs is an inverse to the function values:Lemma 5: elem e (exprs ns) ⇔ values e == nsProof: by induction on the length of ns, using Lemmas 3 and 4Finally, it is now straightforward to state and prove that our brute force imple-mentation is correct, in the sense that the function solutions returns the list of allexpressions that satisfy the predicate solution:Theorem 6: elem e (solutions ns n) ⇔ solution e ns nProof:elem e (solutions ns n)⇔ { deﬁnition of solutions }elem e [e ′ | ns ′ ← subbags ns , e ′ ← exprs ns ′, eval e ′ == [n ] ]⇔ { list comprehensions, Lemma 2 }elem e [e ′ | ns ′ ← subbags ns , e ′ ← exprs ns ] ∧ eval e == [n ]⇔ { simpliﬁcation }or [elem e (exprs ns ′) | ns ′ ← subbags ns ] ∧ eval e == [n ]⇔ { Lemma 5 }or [values e == ns ′ | ns ′ ← subbags ns ] ∧ eval e == [n ]⇔ { deﬁnition of elem }elem (values e) (subbags ns) ∧ eval e == [n ]⇔ { deﬁnition of solution }solution e ns n5 Fusing generation and evaluationThe function solutions generates all possible expressions over the source numbers,but many of these expressions will typically be invalid (fail to evaluate), becausenon-zero naturals are not closed under subtraction and division. For example, thereare 33,665,406 possible expressions over the source numbers [1, 3, 7, 10, 25, 50], butonly 4,672,540 of these expressions are valid, which is just under 14%.In this section we calculate an equivalent but more eﬃcient program by fusingtogether the generation and evaluation phases to give a new function results thatperforms both tasks simultaneously, thus allowing invalid expressions to be rejected6 G. Huttonat an earlier stage. We start by deﬁning a type Result of valid expressions pairedwith their values, together with a speciﬁcation for results:type Result = (Expr , Int)results :: [Int ]→ [Result ]results ns = [(e,n) | e ← exprs ns,n ← eval e ]Using this speciﬁcation, we can now calculate an implementation for results byinduction on the length of ns. For the base cases length ns = 0 and length ns = 1,simple calculations show that results [ ] = [ ] and results [n ] = [(Val n,n) | n > 0].For the inductive case length ns > 1, we calculate as follows:results ns= { deﬁnition of results }[(e,n) | e ← exprs ns,n ← eval e ]= { deﬁnition of exprs , simpliﬁcation }[(e,n) | (ls , rs)← nesplit ns, l ← exprs ls ,r ← exprs rs , e ← combine l r ,n ← eval e ]= { deﬁnition of combine, simpliﬁcation }[(App o l r ,n) | (ls , rs)← nesplit ns, l ← exprs ls ,r ← exprs rs , o ← ops ,n ← eval (App o l r)]= { deﬁnition of eval , simpliﬁcation }[(App o l r , apply o x y) | (ls , rs)← nesplit ns , l ← exprs ls ,r ← exprs rs , o ← ops , x ← eval l , y ← eval r , valid o x y ]= { moving the x and y generators }[(App o l r , apply o x y) | (ls , rs)← nesplit ns , l ← exprs ls ,x ← eval l , r ← exprs rs , y ← eval r , o ← ops , valid o x y ]= { induction hypothesis, Lemma 4 }[(App o l r , apply o x y) | (ls , rs)← nesplit ns , (l , x )← results ls,(r , y)← results rs, o ← ops , valid o x y ]= { simpliﬁcation (see below) }[res | (ls , rs)← nesplit ns, lx ← results ls,ry ← results rs, res ← combine′ lx ry ]The ﬁnal step above introduces an auxiliary function combine ′ that combines tworesults using each of the four arithmetic operators:combine ′ :: Result → Result → [Result ]combine ′ (l , x ) (r , y) = [(App o l r , apply o x y) | o ← ops , valid o x y ]In summary, we have calculated the following implementation for results:results :: [Int ]→ [Result ]results [ ] = [ ]results [n ] = [(Val n,n) | n > 0]results ns = [res | (ls , rs)← nesplit ns , lx ← results ls,ry ← results rs , res ← combine′ lx ry ]Using results, we can now deﬁne a new function solutions ′ that returns the list ofFunctional pearls 7all expressions that solve an instance of the countdown problem by generating allpossible results over each subbag of the source numbers, and then selecting thoseexpressions whose value is the target number:solutions ′ :: [Int ]→ Int → [Expr ]solutions ′ ns n = [e | ns ′ ← subbags ns , (e,m)← results ns ′,m == n ]It is now straightforward to show that our fused implementation is correct, in thesense that it has the same behaviour as our brute force version:Theorem 7: solutions ′ = solutionsProof:solutions ′ ns n= { deﬁnition of solutions ′ }[e | ns ′ ← subbags ns, (e,m)← results ns ′,m == n ]= { speciﬁcation of results, simpliﬁcation }[e | ns ′ ← subbags ns, e ← exprs ns,m ← eval e,m == n ]= { simpliﬁcation }[e | ns ′ ← subbags ns, e ← exprs ns, eval e == [n ] ]= { deﬁnition of solutions }solutions ns nIn terms of performance, solutions ′ [1, 3, 7, 10, 25, 50] 765 returns the ﬁrst so-lution in 0.08 seconds (just over 10 times faster than solutions) and all solutionsin 5.76 seconds (almost 20 times faster), while if the target is changed to 831 theempty list is returned in 5.40 seconds (almost 20 times faster).6 Exploiting arithmetic propertiesThe language of arithmetic expressions is not a free algebra, but is subject toequational laws. For example, the equation x + y = y + x states that addition iscommutative, while x / 1 = x states that 1 is the right identity for division. In thissection we make a further improvement to our countdown program by exploitingsuch arithmetic properties to reduce the search and solution spaces.Recall the predicate valid that decides if applying an operator to two non-zeronaturals gives another non-zero natural. This predicate can be strengthened to takeaccount of the commutativity of addition and multiplication by requiring that theirarguments are in numerical order, and the identity properties of multiplication anddivision by requiring that the appropriate arguments are non-unitary:valid ′ :: Op → Int → Int → Boolvalid ′ Add x y = x  yvalid ′ Sub x y = x > yvalid ′ Mul x y = x = 1 ∧ y = 1 ∧ x  yvalid ′ Div x y = y = 1 ∧ x ‘mod ‘ y == 0Using this new predicate gives a new version of our formal speciﬁcation of the8 G. Huttoncountdown problem. Although we do not have space to present the full details here,this new speciﬁcation is sound with respect to our original speciﬁcation, in the sensethat any expression that is a solution under the new version is also a solution underthe original. Conversely, the new speciﬁcation is also complete up to equivalenceof expressions under the exploited arithmetic properties, in the sense that anyexpression that is a solution under the original speciﬁcation can be rewritten togive an equivalent solution under the new version.Using valid ′ also gives a new version of our fused implementation, which we writeas solutions ′′. This new implementation requires no separate proof of correctnesswith respect to our new speciﬁcation, because none of the proofs in previous sectionsdepend upon the deﬁnition of valid , and hence our previous correctness results stillhold under changes to this predicate. However, using solutions ′′ can considerably re-duce the search and solution spaces. For example, solutions ′′ [1, 3, 7, 10, 25, 50] 765only generates 245,644 valid expressions, of which 49 are solutions, which is justover 5% and 6% respectively of the numbers using solutions ′.As regards performance, solutions ′′ [1, 3, 7, 10, 25, 50] 765 now returns the ﬁrstsolution in 0.04 seconds (twice as fast as solutions ′) and all solutions in 0.86 seconds(almost 7 times faster), while for the target number 831 the empty list is returnedin 0.80 seconds (almost 7 times faster). More generally, given any source and targetnumbers from the television version of the countdown problem, our ﬁnal programsolutions ′′ typically returns all solutions in under one second, and we have yet toﬁnd such a problem for which it requires more than three seconds.7 Further workPossible directions for further work include the use of tabulation or memoisationto avoid repeated computations, exploiting additional arithmetic properties suchas associativity to further reduce the search and solution spaces, and generatingexpressions from the bottom-up rather than from the top-down.AcknowledgementsThanks to Richard Bird, Colin Runciman and Mike Spivey for useful comments,and to Ralf Hinze for the lhs2TeX system for typesetting Haskell code.ReferencesBird, Richard, & Wadler, Philip. (1988). An Introduction to Functional Programming.Prentice Hall.Launchbury, John. (1993). Lazy Imperative Programming. Proceedings of the ACM SIG-PLAN Workshop on State in Programming Languages.Peyton Jones, Simon. (2001). Haskell 98: A Non-strict, Purely Functional Language.Available from www.haskell.org.Spivey, Mike. (1990). A Functional Theory of Exceptions. Science of Computer Program-ming, 14(1), 25–43.

Nottingham ePrints

A Functional Theory of Exceptions.

An Introduction to Functional Programming.

Haskell 98: A Non-strict, Purely Functional Language. Available from www.haskell.org.

Lazy Imperative Programming.

http://www.cs.nott.ac.uk/%7Egmh/countdown.pdf

The Countdown Problem

Abstract

Similar works

Full text

Available Versions

Name not available

Nottingham eTheses

Repository@Nottingham

Name not available

Nottingham ePrints