├── .gitignore ├── MS4P.pdf ├── MS4P.tex ├── README.md └── asked ├── Fmla.ask └── Poly.ask /.gitignore: -------------------------------------------------------------------------------- 1 | ## Core latex/pdflatex auxiliary files: 2 | *.aux 3 | *.lof 4 | *.log 5 | *.lot 6 | *.fls 7 | *.out 8 | *.toc 9 | *.fmt 10 | *.fot 11 | *.cb 12 | *.cb2 13 | .*.lb 14 | 15 | ## Intermediate documents: 16 | *.dvi 17 | *.xdv 18 | *-converted-to.* 19 | # these rules might exclude image files for figures etc. 20 | # *.ps 21 | # *.eps 22 | # *.pdf 23 | 24 | ## Generated if empty string is given at "Please type another file name for output:" 25 | .pdf 26 | 27 | ## Bibliography auxiliary files (bibtex/biblatex/biber): 28 | *.bbl 29 | *.bcf 30 | *.blg 31 | *-blx.aux 32 | *-blx.bib 33 | *.run.xml 34 | 35 | ## Build tool auxiliary files: 36 | *.fdb_latexmk 37 | *.synctex 38 | *.synctex(busy) 39 | *.synctex.gz 40 | *.synctex.gz(busy) 41 | *.pdfsync 42 | 43 | ## Build tool directories for auxiliary files 44 | # latexrun 45 | latex.out/ 46 | 47 | ## Auxiliary and intermediate files from other packages: 48 | # algorithms 49 | *.alg 50 | *.loa 51 | 52 | # achemso 53 | acs-*.bib 54 | 55 | # amsthm 56 | *.thm 57 | 58 | # beamer 59 | *.nav 60 | *.pre 61 | *.snm 62 | *.vrb 63 | 64 | # changes 65 | *.soc 66 | 67 | # comment 68 | *.cut 69 | 70 | # cprotect 71 | *.cpt 72 | 73 | # elsarticle (documentclass of Elsevier journals) 74 | *.spl 75 | 76 | # endnotes 77 | *.ent 78 | 79 | # fixme 80 | *.lox 81 | 82 | # feynmf/feynmp 83 | *.mf 84 | *.mp 85 | *.t[1-9] 86 | *.t[1-9][0-9] 87 | *.tfm 88 | 89 | #(r)(e)ledmac/(r)(e)ledpar 90 | *.end 91 | *.?end 92 | *.[1-9] 93 | *.[1-9][0-9] 94 | *.[1-9][0-9][0-9] 95 | *.[1-9]R 96 | *.[1-9][0-9]R 97 | *.[1-9][0-9][0-9]R 98 | *.eledsec[1-9] 99 | *.eledsec[1-9]R 100 | *.eledsec[1-9][0-9] 101 | *.eledsec[1-9][0-9]R 102 | *.eledsec[1-9][0-9][0-9] 103 | *.eledsec[1-9][0-9][0-9]R 104 | 105 | # glossaries 106 | *.acn 107 | *.acr 108 | *.glg 109 | *.glo 110 | *.gls 111 | *.glsdefs 112 | *.lzo 113 | *.lzs 114 | *.slg 115 | *.slo 116 | *.sls 117 | 118 | # uncomment this for glossaries-extra (will ignore makeindex's style files!) 119 | # *.ist 120 | 121 | # gnuplot 122 | *.gnuplot 123 | *.table 124 | 125 | # gnuplottex 126 | *-gnuplottex-* 127 | 128 | # gregoriotex 129 | *.gaux 130 | *.glog 131 | *.gtex 132 | 133 | # htlatex 134 | *.4ct 135 | *.4tc 136 | *.idv 137 | *.lg 138 | *.trc 139 | *.xref 140 | 141 | # hyperref 142 | *.brf 143 | 144 | # knitr 145 | *-concordance.tex 146 | # TODO Uncomment the next line if you use knitr and want to ignore its generated tikz files 147 | # *.tikz 148 | *-tikzDictionary 149 | 150 | # listings 151 | *.lol 152 | 153 | # luatexja-ruby 154 | *.ltjruby 155 | 156 | # makeidx 157 | *.idx 158 | *.ilg 159 | *.ind 160 | 161 | # minitoc 162 | *.maf 163 | *.mlf 164 | *.mlt 165 | *.mtc[0-9]* 166 | *.slf[0-9]* 167 | *.slt[0-9]* 168 | *.stc[0-9]* 169 | 170 | # minted 171 | _minted* 172 | *.pyg 173 | 174 | # morewrites 175 | *.mw 176 | 177 | # newpax 178 | *.newpax 179 | 180 | # nomencl 181 | *.nlg 182 | *.nlo 183 | *.nls 184 | 185 | # pax 186 | *.pax 187 | 188 | # pdfpcnotes 189 | *.pdfpc 190 | 191 | # sagetex 192 | *.sagetex.sage 193 | *.sagetex.py 194 | *.sagetex.scmd 195 | 196 | # scrwfile 197 | *.wrt 198 | 199 | # svg 200 | svg-inkscape/ 201 | 202 | # sympy 203 | *.sout 204 | *.sympy 205 | sympy-plots-for-*.tex/ 206 | 207 | # pdfcomment 208 | *.upa 209 | *.upb 210 | 211 | # pythontex 212 | *.pytxcode 213 | pythontex-files-*/ 214 | 215 | # tcolorbox 216 | *.listing 217 | 218 | # thmtools 219 | *.loe 220 | 221 | # TikZ & PGF 222 | *.dpth 223 | *.md5 224 | *.auxlock 225 | 226 | # titletoc 227 | *.ptc 228 | 229 | # todonotes 230 | *.tdo 231 | 232 | # vhistory 233 | *.hst 234 | *.ver 235 | 236 | # easy-todo 237 | *.lod 238 | 239 | # xcolor 240 | *.xcp 241 | 242 | # xmpincl 243 | *.xmpi 244 | 245 | # xindy 246 | *.xdy 247 | 248 | # xypic precompiled matrices and outlines 249 | *.xyc 250 | *.xyd 251 | 252 | # endfloat 253 | *.ttt 254 | *.fff 255 | 256 | # Latexian 257 | TSWLatexianTemp* 258 | 259 | ## Editors: 260 | # WinEdt 261 | *.bak 262 | *.sav 263 | 264 | # Texpad 265 | .texpadtmp 266 | 267 | # LyX 268 | *.lyx~ 269 | 270 | # Kile 271 | *.backup 272 | 273 | # gummi 274 | .*.swp 275 | 276 | # KBibTeX 277 | *~[0-9]* 278 | 279 | # TeXnicCenter 280 | *.tps 281 | 282 | # auto folder when using emacs and auctex 283 | ./auto/* 284 | *.el 285 | 286 | # expex forward references with \gathertags 287 | *-tags.tex 288 | 289 | # standalone packages 290 | *.sta 291 | 292 | # Makeindex log files 293 | *.lpz 294 | 295 | # xwatermark package 296 | *.xwm 297 | 298 | # REVTeX puts footnotes in the bibliography by default, unless the nofootinbib 299 | # option is specified. Footnotes are the stored in a file with suffix Notes.bib. 300 | # Uncomment the next line to have this generated file ignored. 301 | #*Notes.bib 302 | -------------------------------------------------------------------------------- /MS4P.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/pigworker/MS4P/1b9c6e8efd0b6f123eca835151fd57dee7815841/MS4P.pdf -------------------------------------------------------------------------------- /MS4P.tex: -------------------------------------------------------------------------------- 1 | \documentclass{book} 2 | \usepackage{amssymb} 3 | \usepackage{latexsym} 4 | \usepackage{amsmath} 5 | \usepackage{stmaryrd} 6 | 7 | \begin{document} 8 | 9 | \newtheorem{puz}{Puzzle}[chapter] 10 | 11 | 12 | \title{Mathematical Structure for Programming} 13 | \author{Conor McBride} 14 | \maketitle 15 | 16 | 17 | %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 18 | \chapter{spuds and a lemon} 19 | %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 20 | 21 | Let's make some numbers! You'll need a bag of lemons, a sack of potatoes, and a load of sticks (e.g. cocktail sticks) which are pointy at both ends. (If you have suitable electrodes and wires, you can make batteries as well as number.) 22 | 23 | There are two ways to get a number in your hand: 24 | \begin{enumerate} 25 | \item grab a lemon---it's a number all by itself; 26 | \item if you already have a number in your hand, stab the thing in your hand with a stick (don't stab your hand), then press a potato onto the other end of the stick and hold onto that potato instead 27 | \end{enumerate} 28 | 29 | \newcommand{\spud}{\mbox{spud}\!\!\!-\!\!\!} 30 | \newcommand{\lemon}{\mbox{lemon}} 31 | So that means we can make (with your hand on the left) 32 | \[\begin{array}{l} 33 | \lemon\\ 34 | \spud\lemon\\ 35 | \spud\spud\lemon\\ 36 | \spud\spud\spud\lemon\\ 37 | \vdots 38 | \end{array}\] 39 | 40 | (Incidentally, a crucial ``let's pretend'' in this game is that you can tell potatoes apart from lemons, but that blind to any difference between two potatoes or between two lemons.) 41 | 42 | Now, if you only make numbers this way, starting only with a lemon and holding onto only the most recently joined potato, your numbers will all have an important property. \textbf{If you follow the sticks down the number, you will eventually get to the lemon.} No sneaky moves, like making a circular model from potatoes and sticks, or always adding on the next potato just in time. 43 | 44 | If you're thinking ``Those aren't numbers: that's just sculpture with groceries!'', then I have two things to tell you. 45 | \begin{enumerate} 46 | \item Our silly models with potatoes and lemons held together by sticks are as valid a representation of numbers as $5$ or MMXXIV. 47 | \item Count the spuds! 48 | \end{enumerate} 49 | But how do you know you \emph{can} count the spuds? How do you know that you won't just keep counting for ever? It's because you eventually get to the lemon. 50 | 51 | 52 | \section{addition as substitution} 53 | 54 | Adding these numbers is easy. If you're holding one of them in each hand, work your way along the left number until you reach the left lemon, then detach it, and stab the right number with the exposed stick, then work your way back out to the leftmost spud. In other words, \emph{substitute} the right \emph{number} for the left \emph{lemon} 55 | \[\begin{array}{l@{\;\,}l} 56 | \spud\spud\spud\spud\spud&\lemon\\ 57 | &+ \\ 58 | &\spud\spud\spud\spud\spud\spud\lemon\\ 59 | &= \\ 60 | \spud\spud\spud\spud\spud&\spud\spud\spud\spud\spud\spud\lemon\\ 61 | \end{array} 62 | \] 63 | Note that the effectiveness of this procedure relies on the fact that you are guaranteed to find the left lemon. 64 | 65 | It's also worth asking these three things: 66 | \begin{enumerate} 67 | \item What if the number in your left hand is a lemon? (You replace the lemon in your left hand with the number in your right, and the answer is exactly the right number.) 68 | \item What if the number in your right hand is a lemon? (You replace the left lemon by the lemon in your right hand and the answer is indistinguishable from the left number you started with.) 69 | \item What if you add three things? Does it matter whether you add left to middle first, or middle to right? (It doesn't matter. Both ways round, you end up with all the spuds you started with, in the same order (not that you can tell), and the rightmost lemon on the end.) 70 | \end{enumerate} 71 | 72 | 73 | \section{synchronized spuds make a race to the lemon} 74 | 75 | Suppose you are holding two numbers (left and right, say), each by their most recent potato. What will happen if you work your way towards the two lemons in tandem, one potato per step in each? Remember that for both numbers, you are sure that stepping in this way means you will eventually get to the lemon? It's a race to the lemon! There are three possibilities: 76 | \begin{itemize} 77 | \item you reach the left lemon while the right number still has a potato. That means the original left number was strictly smaller than the original right number, and now that the left number is a lemon, the current right number is the \emph{difference}. As it were, you have found out that the original numbers were $x$ and $x+\spud y$ for some $x$ and $y$; 78 | \item you reach the left lemon and the right lemon at the same time --- the dead heat means the numbers were both some $x$; 79 | \item you reach the right lemon while the left number still has a potato. So the original left number was greater and the current left number is by how much. The original numbers were $x+\spud y$ and $x$, for some $x$ and $y$. 80 | \end{itemize} 81 | 82 | You should notice that, in all three cases, the number which won the lemon race, called $x$ above, is the largest number from which you can reach \emph{both} numbers by \emph{adding}. You either add $\lemon$ and $\spud y$, $\lemon$ and $\lemon$, or $\spud y$ and $\lemon$, respectively. You have figured out how close you can get to both numbers by adding, together with what the differences are. In other words, we're \emph{undoing} adding by as little as possible. Here, at least one of the differences is nothing, and when the inputs are equal they both are. 83 | 84 | It's funny: this lemon race tells you `maximum' and `minimum', `less than, equal, or greater than', and `difference' all at once. The usual mathematical or programming presentation makes all of these tests and operations distinct, but they are all incomplete facets of the same underlying computation. (The same is true of computations in hardware using binary numbers.) 85 | 86 | 87 | \section{Euclid's lemon racing game} 88 | 89 | Here's a game that the Greek mathematician Euclid used to play with potatoes and lemons.\footnote{Consider a pinch of historical salt.} It's a game which computes one number from two. 90 | 91 | You start with two numbers, one in each hand. If one hand holds a lemon, stop: the answer is the number in your other hand! Otherwise, run a lemon race. Now, at least one hand is holding a lemon: put that hand back to the start of its number; keep the other hand where it is and detach any potatoes you passed by to get there. That's to say, replace the larger number by the difference. Go back to the start. 92 | 93 | Why does this game reach an end? Because you don't run the lemon race unless you start with potatoes in both hands, so each step will result i one or other hand moving strictly nearer its lemon, and both sides promise that you eventually get to the lemon. 94 | 95 | But, perhaps more importantly, what on earth is the meaning of the output of this game? 96 | 97 | (Some people have been known to tell a version of this story in which Euclid repeatedly breaks the largest square possible off from a rectangular piece of chocolate\footnote{Likewise.} until there is no chocolate left. I find the spuds and lemons version more savoury, because nobody wants a rectangle of chocolate with width zero.) 98 | 99 | 100 | \section{puzzles} 101 | 102 | \begin{puz} 103 | An `add-respects-or' test is a computable way to decide a true-or-false property of spuds-and-lemon numbers such that 104 | \begin{itemize} 105 | \item the test gives false for a $\lemon$; 106 | \item whenever you can split up any number $x$ as $y+z$ in any way, the test gives true for $x$ if and only if the test gives true either for $y$ or for $z$ or for both. 107 | \end{itemize} 108 | A `boring' test is one which always gives the same answer, no matter what number you test. 109 | \begin{enumerate} 110 | \item Find one boring add-respects-or test. 111 | \item Either find a different boring add-respects-or test, or explain why no such test exists. 112 | \item Find an add-respects-or test which is \emph{not} boring. 113 | \item Either find a different non-boring add-respects-or test, or explain why no such test exists. 114 | \end{enumerate} 115 | (To show that two tests are different, you must be able to explain why there is some number where they disagree.) 116 | \end{puz} 117 | 118 | \begin{puz} 119 | Let us say that a number is `munky' if it is exactly divisible by three, `minky' if division by three leaves a remainder of one, and `manky' if division by three leaves a remainder of two. Explain how to test these properties of spuds-and-lemon numbers. You should be able to remove one spud at a time and test what is left. After all, you will eventually get to the lemon! Hint: it is easier to solve all three parts of this puzzle together, rather than taking the one at a time. 120 | \end{puz} 121 | 122 | \begin{puz} 123 | Our method of addition replaced the left $\lemon$ by the right number. You could also consider computations which replace each $\spud$ in a number by the same something (which had better be ready to attach to a number). What can you compute in this way? 124 | \end{puz} 125 | 126 | \begin{puz} 127 | Our method of addition dismantles the left number and keeps the right number intact. It is thus far from obvious that $x+y = y+x$. Devise a method for adding in a way which is conspicuously symmetrical. Do the same for multiplication. 128 | \end{puz} 129 | 130 | \begin{puz} 131 | A `multiply-respects-or' test is a computable way to decide a true-or-false property of spuds-and-lemon numbers such that 132 | \begin{itemize} 133 | \item the test gives false for $\spud\lemon$; 134 | \item whenever you can split up any number $x$ as $y\times z$ in any way, the test gives true for $x$ if and only if the test gives true either for $y$ or for $z$ or for both. 135 | \end{itemize} 136 | \begin{enumerate} 137 | \item Are any of your `minky', `manky', `munky' tests multiply-respects-or? If so, which and why? 138 | \item In a black box, I have a multiply-respects-or test which is not boring. What answer does it give for the $\lemon$? No, you may not look in the box! 139 | \item Is divisibility by \emph{four} a multiply-respects-or test? Why? 140 | \item What are the non-boring multiply-respects-or tests? (Note: it's terribly unfair of me to ask this question at this stage, but we'll make sense of it eventually.) 141 | \end{enumerate} 142 | \end{puz} 143 | 144 | 145 | %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 146 | \chapter{seeing the trees} 147 | %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 148 | 149 | Computer programs are written in formal languages. You can't just say any old thing and expect a computer to make sense of it, even if these days they're quite willing to bullshit you that they understand. Computer programs tend to be written textually, as a sequence of \emph{lines}, each of which is a sequence of \emph{characters} (i.e., letters, digits, spaces, punctuation, emoji, etc), and that's not particularly helpful if you're trying to understand them---it's merely a convenient fit with our ancient methods for writing stuff down. Text doesn't have much obvious structure, but computer programs do. We need to learn to see, and to talk about how to see. 150 | 151 | We have a language (the language of \emph{grammars}) for talking about languages. Let me start with an example 152 | \newcommand{\nt}[1]{\langle\mathit{#1}\rangle} 153 | \[\begin{array}{rrl} 154 | \nt{Number} & ::= & \lemon\\ 155 | & | & \spud\nt{Number} 156 | \end{array}\] 157 | How to read this? Where to begin? Which of these things is nearest to hand? You can't be expected to know until someone establishes the conventions. 158 | 159 | The place to start is with $::=$, which you can pronounce `is defined to be'. It's a variation on the theme of $=$, but with a particular spin. You're not being asked to agree with this equation, and there's no way you can check it. You're not supposed to think (or pretend) `Oh I knew that!'. When I write this equation, I'm telling you something \emph{new}, and asking you to put up with it for the time being. 160 | 161 | The thing to the left of $::=$ is the name of a new \emph{sort of thing}---by convention, the names of sorts of things are written in $\nt{\cdot}$ to distinguish them from \emph{actual} things. The $\nt{\cdot}$ does the job of `a' or `an' in English---the indefinite article---we're talking about a generic class of things by imagining one, but not a special one. What I'm saying is `I'm inventing a new sort of thing, namely a $\mathit{Number}$, and I'm telling you of what a $\mathit{Number}$ may consist.'. Everything after $::=$ is the explanation of what I allow these $\mathit{Number}$s to be. 162 | 163 | The next thing to pay attention to is the $|$ which you can read as `or'. I'm giving you a choice of ways to make $\mathit{Number}$s. 164 | 165 | The first choice I offer is `$\lemon$'. See? In English prose I write it in quotation marks, because I mean the actual word `$\lemon$'. It's not a \emph{variable} which could stand abstractly for a variety of things. It's concretely what it says. 166 | 167 | The second choice I offer is the concrete symbol `$\spud{\,}$' which again (because no $\nt{\cdot}$) means only what it says, followed by $\nt{Number}$. The latter indicates that any $\mathit{Number}$ you have made already can go in that place. 168 | 169 | I didn't offer any other choices. Implicit in this definition is that it is \emph{exhaustive}. Spuds and lemons, that's your lot! I'm saying ``I'm inventing a new sort of thing, namely a $\mathit{Number}$, which consists either of `$\lemon$' or of `$\spud{}$' followed by another $\mathit{Number}$.'' and I'm also saying ``You can't possibly have \emph{finished} making a $\mathit{Number}$ unless you eventually get to a `$\lemon$'.''. 170 | 171 | So what are these $\mathit{Number}$s? 172 | \[\begin{array}{r} 173 | \lemon \\ 174 | \spud\lemon \\ 175 | \spud\spud\lemon \\ 176 | \spud\spud\spud\lemon \\ 177 | \vdots 178 | \end{array}\] 179 | But these examples and the `and so on' indicated by `$\vdots$', don't tell us precisely what $\mathit{Number}$s are, in general, whereas the grammar does. 180 | 181 | \newcommand{\nta}[2]{\begin{array}[b]{l} #2\\ \uparrow\\ \nt{#1}\end{array}} 182 | The grammar does another useful thing, as well. It tells us how to perceive a $\mathit{Number}$ as a structure. We can draw a picture of how to see $\spud\spud\lemon$ as a $\mathit{Number}$: 183 | \[\nta{Number}{\spud\nta{Number}{\spud\nta{Number}{\lemon}}}\] 184 | I've drawn this picture, which is called a `parse tree', with the bottom nearest to hand (they're sometimes drawn the other way up), so you should read it bottom-to-top, like a detective, even though time went top-to-bottom\footnote{In the beginning was the $\lemon$\ldots}. It records how the choices offered by the grammar can be employed to make sense of the text. 185 | 186 | Old computer scientists \emph{see} these trees when we \emph{look} at text. We don't even notice that we're doing it, but we experience distress when it doesn't just happen automatically and we look for someone else to blame. You are not born with this mode of perception, and it may take some practice to acquire it. 187 | 188 | 189 | \section{what's in a grammar (and what isn't)?} 190 | 191 | \newcommand{\X}{\mathsf{X}} 192 | \newcommand{\SB}{\mathsf{SumBelow}\;} 193 | \newcommand{\SH}{\mathsf{Shift}\;} 194 | Let's have another grammar with a little more to it. It's a little language of formulae involving one variable $\X$. 195 | \[\begin{array}{rrl} 196 | \nt{Formula} 197 | & ::= & \X \\ 198 | & | & \nt{Number} \\ 199 | & | & \nt{Formula} * \nt{Formula} \\ 200 | & | & \nt{Formula} + \nt{Formula} \\ 201 | %& | & \SB \nt{Formula} \\ 202 | %& | & \SH \nt{Formula} \\ 203 | & | & (\nt{Formula}) 204 | \end{array}\] 205 | 206 | What do we notice? Firstly, we have two ways to make a formula with no subformulae---the variable, $\X$ and any number you like. We could insist that numbers be written in $\spud\lemon$ form, but let's allow ourselves the brevity of Arabic numerals. That means we're in a position to make an `eventually reaching the $\lemon$' promise about formulae: if you keep tearing formulae apart, you eventually reach $\X$ or a number (in which you eventually reach the $\lemon$). 207 | 208 | Secondly, we have choices with \emph{two} subformulae. That means our parse trees can spread out like they're called trees for a reason. E.g., $(\X + 2)*\X$ has parse tree 209 | \[ 210 | \nta{Formula}{(\nta{Formula}{\nta{Formula}{\X} + \nta{Formula}{\nta{Number}{2}}})} 211 | * 212 | \nta{Formula}{\X} 213 | \] 214 | If we're exploring the parse tree, we have a choice of paths we can take. Our `eventually $\lemon$' promise has to get stronger: you eventually reach $\X$ or a number, \emph{whatever path you choose}. 215 | 216 | Thirdly, I haven't said anything about what these formulae mean. You might \emph{think} you know what $+$ and $*$ mean, because they look like standard symbols for addition and multiplication, but I haven't confirmed that that's what \emph{I} mean by them. Grammars don't say what things mean---they filter and structure texts which are \emph{plausible}, discarding texts which are obvious \emph{gibberish}. That's to say they \emph{ask} helpful questions about the meanings of some things in particular, but they don't offer any \emph{answers}. 217 | 218 | Fourthly, the grammar is \emph{ambiguous}. It is not immediately obvious whether $2+\X*\X$ says 219 | \[ 220 | \nta{Formula}{\nta{Formula}{2}+\nta{Formula}{\nta{Formula}{\X}*\nta{Formula}{\X}}} 221 | \] 222 | or 223 | \[ 224 | \nta{Formula}{\nta{Formula}{\nta{Formula}{2}+\nta{Formula}{\X}}*\nta{Formula}{\X}} 225 | \] 226 | Worse, we do not automatically know whether $\X+\X+\X$ groups to the left or to the right, and we might hope not to care, but for now we must worry about it. You may have learned some rules at school about this sort of thing, and that's good, because at least you can see we might need rules to manage this sort of situation. But I'm a \emph{university} teacher, so I can take school rules, grind them to a powder and blow them out the window, if I feel that would improve my day. 227 | The simplest strategy to deal with ambiguity is to reject ambiguous texts, given that our grammar lets us use parentheses to resolve them: at least, that's what we might \emph{hope} the parentheses are for. At the moment, we have no reason to believe $\X$, $(\X)$ and $((\X))$ will all mean the same thing, and there are computer languages where wrapping extra sets of parentheses round stuff really does change its meaning. 228 | 229 | As a side remark, one awkward consequence of mathematics being taught at school to some fairly standardised curriculum is a misplaced entitlement to notation working in all sorts of contexts the way it did in that context. One symptom of this malaise is the presumption that parentheses $(\cdot)$, brackets $[\cdot]$ and braces $\{\cdot\}$ are interchangeable and serve only to indicate grouping. This is very seldom, if ever, the case in computer programming languages, or in the notations we use to write about them. You should never expect $[x]$ to mean the same as $x$. 230 | 231 | For \emph{this} particular language of formulae, I'm willing to promise you that parentheses $(\cdot)$ are used only for grouping, i.e. to choose between possible parse trees. The meaning of a formula with enclosing parentheses will always be the same as that formula without parentheses. I promise you that 232 | \[\nta{Formula}{(\nta{Formula}{\nta{Formula}{\X}+\nta{Formula}{2}})} 233 | \qquad\mbox{and}\qquad 234 | \nta{Formula}{\nta{Formula}{\X}+\nta{Formula}{2}} 235 | \] 236 | with the parenthesesized version needed only to avoid ambiguity when this formula is part of a larger formula. 237 | 238 | The notion of grammar we have here is often called `context-free'. The rules for what constitutes a formula don't change, depending on where the formula is. There are more complex aspects to meaningfulness which context-free grammars can't capture. For example, if we wanted to write the grammar of grammars themselves, we could not enforce the property that every sort of thing mentioned to the right of $::=$ has a unique definition, i.e., occurring to the left of exactly one $::=$ somewhere in the same grammar. That's to say the \emph{scope} of names is exactly the sort of context which context-free grammars can't handle. So, don't expect grammars to encode complicated requirements for coordination between separate regions of a text. 239 | 240 | Grammars give us a way to specify languages which are local, artificial, and closed. Out there, in the wilds of mathematics, there might be subtraction and division and $\pi$ and $\mathsf{Y}$, but when we choose to invent what a $\nt{Formula}$ is in this particular way, we can put all of those cosiderations to one side. There's a certain sense of ``Here, we need only worry about\ldots'' with grammars. Of course, that cuts both ways: I'm within my rights to invent grammars which are local to one puzzle. You cannot simply memorise all the grammars you will ever need. That would be like learning a poem by heart innstead of learning to listen. 241 | 242 | 243 | \section{a note on recursion} 244 | 245 | Both of the grammars we've seen so far have been \emph{recursive}. We've said how to make bigger numbers from smaller numbers, and how to make bigger formulae from smaller formulae. Recursion often makes beginners nervous---circularity is suspicious---I'm not going to make the mistake of playing down that nervousness, in an `Oh, you'll get used to it!' sort of way. I'm here to tell you that it's quite reasonable to be nervous about recursion, and to help you ask the extra questions you will need to reassure yourself about recursions you may encounter in the wild. 246 | 247 | For a start, it helps to make a distinction between two ways in which recursion can make sense. Some recursions are trying to achieve some functionality which are \emph{eventually finished}: these rely on each recursive sub-thing being simpler, with some guarantee that things can't keep getting simpler forever---you eventually stop because you eventually reach a `base case' with no subproblems. Other recursions are trying to achieve some functionality which is \emph{always ready}: it might stop, it might keep going, but it will always let you ask `what's next?'. The latter is how you expect computer games to behave: you might win, you might lose, but you might just keep on going, and you expect the game to keep responding to you. 248 | 249 | The bad recursions never finish but can become unresponsive, and that can happen. Those recursions are worth being afraid of. If you see something defined by recursion, don't run away, but don't assume it makes sense. See if you can find out why it's eventually finished or always ready. 250 | 251 | Now, in our world of grammars, we expect our parse trees to have the property that following any path through them eventually stops. What can we say about Theresa May's famous grammar? 252 | \[\begin{array}{rrl} 253 | \nt{Brexit} & ::= & \nt{Brexit} 254 | \end{array}\] 255 | Is it a bad grammar? No, merely \emph{pointless}! It is well constructed. There is one choice of how to make a Brexit: you make it from a Brexit. So there are no parse trees for this grammar with finite paths, and no text can possibly make sense as a Brexit. 256 | 257 | 258 | \section{abstract syntax trees} 259 | 260 | \newcommand{\D}[1]{\mathtt{#1}} 261 | \newcommand{\C}[1]{\mathtt{#1}} 262 | 263 | Grammars tell us how to see structure in a text. A parse tree shows the original text with that structure imposed upon it. If we want to compute with a formula, perhaps to give it some sort of meaning, it is this structure which matters, not the precise details of the text. We should hope that it doesn't matter\footnote{but I could tell you some horror stories} whether you write $\X+2$ or $\X\;+\;2$, and a few extra sets of parentheses shouldn't make any difference, provided they go round valid subformulae. How do we get our hands on the structure? 264 | 265 | We could, of course, make \emph{models} of these structures from fruit, vegetables, and cocktail sticks. We might use an apple with two sticks coming out to build a formula with $+$, a pear with two sticks for $*$, a nectarine for a numerical formula (with one stick to connect it to a spuds-and-lemon number), and a sprout with no sticks coming out for $\X$. Then we can compute with formulae in the same hand-on way we did with numbers. You always start holding the outermost thing, but you can follow the sticks inwards, ad no matter which way you go, you will eventually get to a nectarine or a sprout. 266 | 267 | The nectarines are important. Conceptually, formulae are distinct from numbers. They are different \emph{types} of thing. If we're holding on to a formula, we expect an apple, a pear, a nectarine or a sprout. If we're holding on to a number, we expect a spud or a lemon. It is visually appealing to write a numerical formula as just the unadorned number itself. But when we're explaining computational processes, it will be helpful to be precise about when we are working with numbers and when we are working with formulae. The number 2 is made from two spuds and a lemon; the formula 2 is made from a nectarine, two spuds and a lemon. 268 | 269 | Note that the apples and pears are ways of making a tree for a formula, just as spuds and lemons make numbers, whereas addition and multiplication are processes we know for \emph{computing} with numbers. We could \emph{interpret} a formula as a calculation to perform with numbers: 270 | \begin{itemize} 271 | \item to interpret an apple formula as a number, interpret both subformulae as numbers, then add those numbers; 272 | \item to interpret a pear formula as a number, interpret both subformulae as numbers, then multiply those numbers; 273 | \item to interpret a nectarine formula as a number, remove the nectarine and give back the number it's connected to. 274 | \end{itemize} 275 | You can see that the above procedure is recursive, but it's the `eventually finished' kind of recursion: it works by taking the formula apart into smaller and smaller pieces. A formula written `$2*3$' turns into 276 | \[\begin{array}{l@{\quad}l} 277 | \spud\spud\lemon & \spud\spud\spud\lemon \\ 278 | | & | \\ 279 | \mbox{nectarine} & \mbox{nectarine} \\ 280 | \multicolumn{2}{c}{\backslash\mbox{pear}/\hspace*{0.7in}} 281 | \end{array}\] 282 | Our procedure tells us first to peel off the nectarines to give us $2$ and $3$ respectively, and then to multiply those numbers, yielding 6. 283 | 284 | But haven't I forgotten something? What if the formula says `$2*\X$'? What on earth are we to do with the sprout? What number shall we return when we see it?\footnote{decem?} We won't know unless somebody tells us. Let us make a virtue of that necessity. To do this procedure properly, we need to be given two inputs, a formula and the number that $\X$ stands for. Now we can give the missing rule: 285 | \begin{itemize} 286 | \item to interpret a sprout formula, copy the number that was given as an input. 287 | \end{itemize} 288 | 289 | So if the formula is `$2*\X$' and the number is 7, we multiply 2 by 7 to compute the output 14. 290 | 291 | 292 | \section{substitute the sprouts} 293 | 294 | Remember when we did adding? We had a left number and a right number, and we replaced the left lemon by the right number. Guess what! We can do something very similar with two formulae. 295 | 296 | Suppose you have a left formula and a right formula. You can make a new formula by replace \emph{all} the left sprouts by copies of the right formula. So if we have `$\X*\X$' on the left and `$\X+2$' on the right, we'll get `$(\X+2)*(\X+2)$' as our new formula. Note that I had to put some extra parentheses in the text of the new formula to make sure it parses unambiguously as the tree I computed: the substitution was not textual but structural. Bear in mind also that our formula trees might not have any sprouts in them: if the left formula is `$5$' and the right formula is `$\X+2$', we'll get $5$ as the result of substituting all of the left sprouts --- all none of them. 297 | 298 | It's also worth asking these three things: 299 | \begin{enumerate} 300 | \item What if the formula in your left hand is a sprout? (You replace the sprout in your left hand with the formula in your right, and the answer is exactly the right formula.) 301 | \item What if the formula in your right hand is a sprout? (You replace all the left sprouts by the copies of the sprout in your right hand and the answer is indistinguishable from the left formula you started with.) 302 | \item What if you substitute three things? Does it matter whether you substitute middle into left first, or right into middle? (It doesn't matter. Both ways round, you end up with the same overall combined formula.) 303 | \end{enumerate} 304 | 305 | Surprised? You shouldn't be. Substituting all the sprouts is a lot like substituting all the lemons. It's just that the way numbers are built means that `all the lemons' means `exactly the lemon you're bound to find at the end', whereas a formula can contain any number (including zero) of sprouts. 306 | 307 | Here's something that might seem a little more surprising. Let's take formulae `$\X*\X$' on the left and `$\X+2$' on the right, again and consider the number $5$. We could 308 | \begin{itemize} 309 | \item either interpret `$\X+2$' with $5$ for $\X$ and get $7$, then interpret `$\X*\X$' with $7$ for $\X$ and get $49$. 310 | \item or substitute to get `$(\X+2)*(\X+2)$', then interpret with $5$ for $\X$ to get $49$. 311 | \end{itemize} 312 | Coincidence? I think not! There's some connection between substituting the formulae and sequencing their interpretations, and it has something to do with the way substituting with a sprout in either hand means `do nothing' and interpreting a sprout means `do nothing' to the number we start with. Does it always work? I could say `yes', but I might be lying. And you could try some experiments, but then you might just get bored before you get unlucky. Let's learn to \emph{prove} it. 313 | 314 | (Also, let's see if we can build trees out of something more manageable than fruit and veg.) 315 | 316 | 317 | %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 318 | \chapter{squish a bunch of stuff} 319 | %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 320 | 321 | If you tap your foot five times, and then you tap your foot six times, you'll have tapped your foot eleven times. There's some kind of relationship between adding up numbers and repetitive action sequences. 322 | 323 | If you have one bag of five potatoes and another of six, combining both bags into one will give you a bag of eleven potatoes. Bags of spuds don't behave this way because they were taught arithmetic at school. Arithmetic behaves this way because it helps us think about bags of spuds. 324 | 325 | If you multiply two by five, that's ten; and two times six is twelve. Adding ten and twelve gives twenty-two, which is twice eleven. There's some kind of relationship between adding up numbers and adding up their doubles. (You may have heard this called ``The Distributive Law'', as if there were only one.) 326 | 327 | If you raise two to the power five, that's thirty-two; and two to the six is sixty-four. I don't expect you to multiply numbers as large as those in your head, but you might add five and six to get eleven, then happen to know that two to the eleven is two thousand and forty-eight. (Having a head full of powers of two is an occupational hazard of programming computers.) Why does that trick work? 328 | 329 | Exactly one of five and six is an odd number, and so is eleven. That's odd! It may seem trivial, but at least one of five and six is positive (as opposed to zero), and eleven is positive too. (The only way the sum of two counts can be zero is if they were both separately zero.) 330 | 331 | My point is that 332 | \[ 333 | 5 + 6 \,=\, 11 334 | \] 335 | is not a random isolated truth. It has a relationship with a whole bunch of other truths about other senses of ``combining stuff'', which all go 336 | \[ 337 | \mbox{Combining the fivey thing with the sixy thing gives you the eleveny thing.} 338 | \] 339 | and of course, five, six and eleven are overly concrete examples---what matters is that they are related by a truth about adding numbers, a truth which somehow survives the translation to a truth about combining $n$y things, be they toe-taps, bags of spuds, or tests for oddness. Moreover, it wasn't only the things which mattered---it was also how they were combined. When we doubled we got a truth about adding, but when we two-to-the-powered we got a truth about multiplying, and when we tested for positivity we got a truth about ``either or both''. 340 | 341 | 342 | \section{pictures of combining} 343 | 344 | \newcommand{\wye}[3]{\begin{array}[b]{@{}c@{}}\underbrace{\!\!#1\;\;#2\!\!}\\ #3\end{array}} 345 | \newcommand{\wir}[2]{\begin{array}[b]{@{}c@{}}#1\\ \mid\\ #2\end{array}} 346 | \newcommand{\wid}[1]{\wir{#1}{#1}} 347 | \newcommand{\naw}[1]{\begin{array}[b]{@{}c@{}}\bullet \vspace*{-0.13in}\\ \mid \\ #1\end{array}} 348 | 349 | We can draw pictures of strategies for combining things like this 350 | \[ 351 | \wye{5}{6}{11} 352 | \] 353 | Data flows from top to bottom. This component 354 | \[ 355 | \wye\downarrow\downarrow\downarrow 356 | \] 357 | has two inputs and one output. We can wire these components together to combine more things. 358 | \[ 359 | \wye{\wye\downarrow\downarrow\mid}\downarrow\downarrow 360 | \] 361 | If we choose what sort of things we're combining (numbers, say) and how (adding, say), then by labelling the wires with data, we can make assertions about the results of combining things. I usually just write the data instead of the wire, so 362 | \[ 363 | \wye{\wye{5}{6}{11}}{7}{18} 364 | \qquad\mbox{asserts}\qquad 365 | 5 + 6 \,=\, 11\quad\mbox{and}\quad 11 + 7 \,=\, 18 366 | \] 367 | but it's allowed to label the same wire more than once as long as you label it with the same thing. Signals don't change value in the middle of a wire. The same calculation is indicated by 368 | \[ 369 | \wye{\wye{5}{6}{11}}{\wid{7}}{\wid{18}} 370 | \] 371 | 372 | Now, some notions of combining things are equipped with ``the sensible way to do nothing''. That's given by a component with no inputs and one output 373 | \[ 374 | \naw{\downarrow} 375 | \qquad\mbox{such that}\qquad 376 | \wye{\naw{}}\cdot\cdot \;=\; \wid\cdot \;=\;\wye\cdot{\naw{}}\cdot 377 | \] 378 | In other words, combining with nothing turns into wire: that the output must be the same as the input is what ``doing nothing'' means. 379 | 380 | For adding numbers, 0 is the right way to do nothing, 381 | \[ 382 | \naw{0} 383 | \qquad\mbox{so for any $n$,}\quad 384 | \wye{\naw{0}}nn \;=\; \wid n \;=\;\wye n{\naw{0}}n 385 | \] 386 | It's very useful to have a sensible way to do nothing. That way, we can look out of an aeroplane window and count the fish, or say how many spuds we have left once we've eaten them all. Our rules tell us that there's only one sensible way to do nothing for any given way of combining. Imagine we had 387 | \[ 388 | \naw{a} \; \mbox{and}\; \naw{b} 389 | \qquad\mbox{then}\qquad 390 | \wir bc\,=\,\wye{\naw{a}}{\naw{b}}c\,=\,\wir ac 391 | \qquad\mbox{so}\qquad a = c = b 392 | \] 393 | That is, on the left, we do the left nothing to the right nothing, and on the right, we do the right nothing to the left nothing: our rules tell us we must end up with the same nothing. So if you see a ``way of combining'', \emph{look} for ``the sensible way to do nothing''---you won't find two, you might find one, and if there's no sensible way to do nothing, that's interesting, too. 394 | 395 | When we're combining a bunch of stuff, we are sometimes in the lucky position that it's the sequence of \emph{the stuff} which determines the result of combining them, not the structure of pairwise combinations we choose. If we add up the list $[5,6,7]$, we get $18$, whether we calculate it this way 396 | \[ 397 | \wye{\wye56{11}}7{18} 398 | \qquad\mbox{or this way}\qquad 399 | \wye5{\wye67{13}}{18} 400 | \qquad\mbox{or even this way}\qquad 401 | \wye5{\wye6{\wye7{\naw0}7}{13}}{18} 402 | \] 403 | 404 | In general, we want 405 | \[ 406 | \wye{\wye\cdot\cdot\mid}\cdot\cdot \;=\; \wye\cdot{\wye\cdot\cdot\mid}\cdot 407 | \] 408 | so that we can regroup the calculation without reordering the inputs and be sure of getting the same output (even though the intermediate data change). That's why we don't bother writing brackets in $5+6+7$. You can combine data onto a ``running total'' one at a time, or you can give half the data to a friend and combine your outputs afterwards. Knowing what doesn't matter makes it far easier to gain confidence about what does! 409 | 410 | Of course, I haven't really demonstrated that only the sequence of the inputs determines the outputs, not the structure of the combination tree. Let me sketch one way to see it. Let me say that one of our diagrams is \emph{listy} if it is always overbalanced as far to the right as possible, and has a nothing in the top right corner, i.e. 411 | \begin{itemize} 412 | \item inputs occur only on the left of $\wye\cdot\cdot\cdot$ 413 | \item only inputs occur on the left of $\wye\cdot\cdot\cdot$ 414 | \end{itemize} 415 | Think carefully about the difference in meaning made by the difference in word order. The first condition rules out 416 | \[ 417 | \wid 6 \quad\mbox{and}\quad \wye56{11} 418 | \] 419 | in both cases because $6$ is somewhere it is not permitted. 420 | The second condition rules out 421 | \[ 422 | \wye{\naw0}66 \quad\mbox{and}\quad \wye{\wye56{11}}7{18} 423 | \] 424 | because some left things are not inputs. 425 | 426 | Each of our sequences of inputs can be put into a listy diagram because 427 | \begin{itemize} 428 | \item if you have no inputs, only $\naw\cdot$ is listy; 429 | \item if you have a first input $x$, you must make $\wye xLt$ where $L$ is the listy diagram made with all but the first input. 430 | \end{itemize} 431 | But that's not enough, because we need to know that \emph{any} diagram can be transformed into its listy counterpart by using the three rules we gave ourselves 432 | \[ 433 | \wye{\naw{}}\cdot\cdot \;=\; \wid\cdot \;=\;\wye\cdot{\naw{}}\cdot \qquad 434 | \wye{\wye\cdot\cdot\mid}\cdot\cdot \;=\; \wye\cdot{\wye\cdot\cdot\mid}\cdot 435 | \] 436 | Here's how: 437 | \begin{itemize} 438 | \item $\naw{}$ is already listy; 439 | \item $\wid\cdot$ can be make listy like this $\wye\cdot{\naw{}}\cdot$; 440 | \item if you have a diagram $\wye{D_0}{D_1}t$, you can make it listy by first making $D_0$ into listy $L_0$ and then making listy $D_1$ into listy $L_1$, so you have $\wye{L_0}{L_1}t$. Now \emph{rotate} the whole thing into being listy like this: 441 | \begin{itemize} 442 | \item if you have $\wye{\naw{}}{L_1}t$, turn it into $L_1$ (whose `total' must already be $t$); 443 | \item if you have $\wye{\wye x{L'_0}\mid}{L_1}t$ rotate it to $\wye x{\wye{L'_0}{L_1}\mid}t$, then keep rotating on the right. 444 | \end{itemize} 445 | \end{itemize} 446 | So we've used all and only the rules we asked for. The rotation process effectively pastes $L_1$ over the $\naw{}$ in the top right corner of $L_0$. 447 | 448 | There are lots of things to say about this ``explanation'', some good, some bad. Does it make sense to you? How would you check it? 449 | 450 | How do you know, for example, that ``then keep rotating on the right'' actually achieves something other than endless rotation? There's a sense that rotation of $\wye{L_0}{L_1}t$ works by looking at $L_0$, and if $L_0 = \wye x{L'_0}\mid$, then we keep rotating with $\wye{L'_0}{L_1}\mid$, where the new diagram on the left, $L'_0$ is smaller than the old diagram on the left $L_0$. As long as we can't keep cutting smaller diagrams out of bigger ones forever, we'll be fine---sooner or later, we'll hit $\naw{}$. But is that explanation of the explanation just more waffle, or is it something we can codify? 451 | 452 | Another potential grumble is that the whole thing depends on inventing this notion of which diagrams are ``listy'', and it looks like I just plucked that definition out of my arse. Where did it really come from? 453 | 454 | As for the positives, for one thing, no numbers got added in the course of this narrative. We said which three rules we needed, and we deduced an ``only the sequence of inputs determines the output'' result for \emph{any} notion of combining things which obeys those rules. If we want the same result for multiplication (where 1 is ``the right way of doing nothing''), we know what we need to check. 455 | 456 | Moreover, our story about pictures of combining things involved inventing a way to combine \emph{listy pictures} of combining \emph{things}. To combine $L_0$ and $L_1$, paste $L_1$ over the $\naw{}$ in the top right corner of $L_0$, or in other words, combine the sequences by concatenating them---joining them up end-of-one-to-start-of-the-next in space. Here $\naw{}$ is the ``right way of doing nothing'', as it represents the empty sequence. 457 | 458 | For example, here are the listy pictures for combining five things and six things, respectively: 459 | \newcommand{\mo}[1]{\wye{\cdot}{#1}{\mid}} 460 | \[ 461 | \wye{\cdot}{\mo{\mo{\mo{\mo{\naw{}}}}}}{\cdot} 462 | \qquad\qquad 463 | \wye{\cdot}{\mo{\mo{\mo{\mo{\mo{\naw{}}}}}}}{\cdot} 464 | \] 465 | and if you combine them, you get 466 | \[ 467 | \wye{\cdot}{\mo{\mo{\mo{\mo{\mo{\mo{\mo{\mo{\mo{\mo{\naw{}}}}}}}}}}}}{\cdot} 468 | \] 469 | which is, of course, the listy picture for combining eleven things, so perhaps numbers \emph{did} get added, after all. 470 | 471 | 472 | \section{it's called a ``monoid''} 473 | 474 | While I'm trying to reduce the number of words by drawing more pictures, we are going to need a name for these ``ways of combining a bunch of stuff''. When I do introduce terminology, I'll try to make it the standard terminology. The standard name is ``monoid'', which is Greek for ``one-ish'', as in ``you can take any sequence of things and combine them into one thing''. Let's review the definition. 475 | 476 | \newcommand{\neu}{\varepsilon} 477 | \newcommand{\com}{\circ} 478 | A \textbf{monoid} is given by a type $T$, a value $\neu$ in $T$, and an operator $\com$ which takes two inputs from $T$ and yields one output in $T$, satisfying the laws 479 | \[ 480 | \neu\com t = t \qquad 481 | t\com\neu = t \qquad 482 | (r\com s)\com t = r\com(s\com t) 483 | \] 484 | We've been drawing 485 | \[ 486 | \naw\neu \qquad \wye st{s\com t} 487 | \] 488 | 489 | 490 | %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 491 | \appendix 492 | %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 493 | 494 | 495 | %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 496 | \chapter{solutions} 497 | %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 498 | 499 | \newtheorem{sol}{Solution}[section] 500 | 501 | \section{spuds and lemons} 502 | 503 | \begin{sol} 504 | An `add-respects-or' test is a computable way to decide a true-or-false property of spuds-and-lemon numbers such that 505 | \begin{itemize} 506 | \item the test gives false for a $\lemon$; 507 | \item whenever you can split up any number $x$ as $y+z$ in any way, the test gives true for $x$ if and only if the test gives true either for $y$ or for $z$ or for both. 508 | \end{itemize} 509 | A `boring' test is one which always gives the same answer, no matter what number you test. 510 | \begin{enumerate} 511 | \item Find one boring add-respects-or test.\\ 512 | \emph{The test which always gives false is certainly boring, and it satisfies both conditions for being add-respects-or.} 513 | \item Either find a different boring add-respects-or test, or explain why no such test exists.\\ 514 | \emph{The only other boring test is the one which always gives true, but it violates the condition that the test must give false for the $\lemon$.} 515 | \item Find an add-respects-or test which is \emph{not} boring. 516 | \emph{The property of containing a $\spud\;$ is false for $\lemon$ but true for all the other numbers, so it is not boring and it satisifies the first criterion. Addition exactly preserves all the $\spud\,$s in the numbers it acts on, so the second condition is satsfied, too.} 517 | \item Either find a different non-boring add-respects-or test, or explain why no such test exists. \emph{Every number can be decomposed as the sum of as many $\spud\lemon$ numbers as there were $\spud\,$s in the first place. As a result, an add-respects-or test for any number with spuds gives the same answer as testing $\spud\lemon$: if that's false, it's boring; if that's true, that's testing for containing a spud; other options are available. } 518 | \end{enumerate} 519 | \end{sol} 520 | 521 | \begin{sol} 522 | Let us say that a number is `munky' if it is exactly divisible by three, `minky' if division by three leaves a remainder of one, and `manky' if division by three leaves a remainder of two. Explain how to test these properties of spuds-and-lemon numbers. You should be able to remove one spud at a time and test what is left. After all, you will eventually get to the lemon! Hint: it is easier to solve all three parts of this puzzle together, rather than taking the one at a time. 523 | 524 | \emph{If you're testing a $\lemon$, it's munky, not minky or manky. Meanwhile $\spud n$ is munky if $n$ is manky, minky if $n$ is munky, and manky if $n$ is minky.} 525 | \end{sol} 526 | 527 | 528 | \begin{sol} 529 | Our method of addition replaced the left $\lemon$ by the right number. You could also consider computations which replace each $\spud$ in a number by the same something (which had better be ready to attach to a number). What can you compute in this way? 530 | 531 | \emph{Multiplication. If you have left and right numbers, removing the right lemon gives you something to replace each left spud with. That will add as many copies of the right number as there are left spuds. } 532 | \end{sol} 533 | 534 | 535 | \begin{sol} 536 | Our method of addition dismantles the left number and keeps the right number intact. It is thus far from obvious that $x+y = y+x$. Devise a method for adding in a way which is conspicuously symmetrical. Do the same for multiplication. 537 | 538 | \emph{You can tear down both numbers at the same time. If either number is a $\lemon$, their sum is the other number. If they're both $\spud\,$s, remove both outermost spuds, add what remains, then attach two spuds to the answer. The key to multiplication is to add at the same time. Here goes. If either number is a $\lemon$, their sum is the other number and their product is a $\lemon$. If they're both $\spud\,$s, remove both outermost spuds, add and multiply what remains; grow the product by the sum and one spud, and grow the sum by two spuds as before.} 539 | \end{sol} 540 | 541 | \begin{sol} 542 | A `multiply-respects-or' test is a computable way to decide a true-or-false property of spuds-and-lemon numbers such that 543 | \begin{itemize} 544 | \item the test gives false for $\spud\lemon$; 545 | \item whenever you can split up any number $x$ as $y\times z$ in any way, the test gives true for $x$ if and only if the test gives true either for $y$ or for $z$ or for both. 546 | \end{itemize} 547 | \begin{enumerate} 548 | \item Are any of your `minky', `manky', `munky' tests multiply-respects-or? If so, which and why?\\ 549 | \emph{Testing for being munky is multiply-respects-or, because $3$ is prime. 550 | Factorising a number amounts to partitioning its prime factors. A $3$ in the whole set of prime factors must end up in one part of the partition. $4$ is a minky number, but $4 = 2*2$ and $2$ is manky, so neither minky nor manky are multiply-respects-or tests.} 551 | \item In a black box, I have a multiply-respects-or test which is not boring. What answer does it give for the $\lemon$? No, you may not look in the box!\\ 552 | \emph{It must give true. Suppose otherwise. Pick any number $n$. Recall that $n*0 = 0$. 553 | That means testing $n$ or false gives false, by respecting or, so testing $n$ gives false. Hence the test is boring.} 554 | \item Is divisibility by \emph{four} a multiply-respects-or test? Why?\\ 555 | \emph{No. $4 = 2*2$, but neither $2$ nor $2$ is divisible by $4$, and $4$ is divisible by $4$, so multiply does not respect or.} 556 | \item What are the non-boring multiply-respects-or tests? (Note: it's terribly unfair of me to ask this question at this stage, but we'll make sense of it eventually.)\\ 557 | \emph{Every number has a unique factorisation into primes, so any multiply-respects-or test is determined exactly by its behaviour on prime numbers. Such a test determines the subset $S$ of prime numbers for which it returns true, and it will thus return true exactly for any number with a factor in $S$. Every subset of the primes gives the $S$ for such a test, and it is only boring when $S$ is empty.} 558 | \end{enumerate} 559 | \end{sol} 560 | 561 | 562 | 563 | \end{document} 564 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # MS4P 2 | being some thoughts about introductory mathematics for computer science 3 | -------------------------------------------------------------------------------- /asked/Fmla.ask: -------------------------------------------------------------------------------- 1 | data N = Z | S N 2 | 3 | (+) :: N -> N -> N 4 | defined x + y inductively x where 5 | defined x + y from x where 6 | defined Z + y = y 7 | defined S x + y = S (x + y) 8 | 9 | (*) :: N -> N -> N 10 | defined x * y inductively x where 11 | defined x * y from x where 12 | defined Z * y = Z 13 | defined S x * y = y + (x * y) 14 | 15 | data Bool = False | True 16 | 17 | data Fmla 18 | = Num N 19 | | Var 20 | | Add Fmla Fmla 21 | | Mul Fmla Fmla 22 | 23 | eval :: Fmla -> N -> N 24 | defined eval f x inductively f where 25 | defined eval f x from f where 26 | defined eval (Num n) x = n 27 | defined eval Var x = x 28 | defined eval (Add f g) x = eval f x + eval g x 29 | defined eval (Mul f g) x = eval f x * eval g x 30 | 31 | sbst :: Fmla -> Fmla -> Fmla 32 | defined sbst f h inductively f where 33 | defined sbst f h from f where 34 | defined sbst (Num n) h = Num n 35 | defined sbst Var h = h 36 | defined sbst (Add f g) h = Add (sbst f h) (sbst g h) 37 | defined sbst (Mul f g) h = Mul (sbst f h) (sbst g h) 38 | 39 | proven eval (sbst f g) n = eval f (eval g n) inductively f where 40 | proven eval (sbst f g) n = eval f (eval g n) from f where 41 | given f = Add a b proven eval (sbst (Add a b) g) n = eval (Add a b) (eval g n) tested where 42 | proven eval (sbst a g) n + eval (sbst b g) n = eval a (eval g n) + eval b (eval g n) under (+) 43 | given f = Mul a b proven eval (sbst (Mul a b) g) n = eval (Mul a b) (eval g n) tested where 44 | proven eval (sbst a g) n * eval (sbst b g) n = eval a (eval g n) * eval b (eval g n) under (*) 45 | 46 | -------------------------------------------------------------------------------- /asked/Poly.ask: -------------------------------------------------------------------------------- 1 | data N = Z | S N 2 | 3 | (+) :: N -> N -> N 4 | defined x + y inductively x where 5 | defined x + y from x where 6 | defined Z + y = y 7 | defined S x + y = S (x + y) 8 | 9 | (*) :: N -> N -> N 10 | defined x * y inductively x where 11 | defined x * y from x where 12 | defined Z * y = Z 13 | defined S x * y = y + (x * y) 14 | 15 | data Bool = False | True 16 | 17 | data Poly 18 | = Num N 19 | | Var 20 | | Add Poly Poly 21 | | Mul Poly Poly 22 | | AfS Poly 23 | | Sum Poly 24 | 25 | sumBelow :: (N -> N) -> N -> N 26 | defined sumBelow f x inductively x where 27 | defined sumBelow f x from x where 28 | defined sumBelow f Z = Z 29 | defined sumBelow f (S x) = sumBelow f x + f x 30 | 31 | eval :: Poly -> N -> N 32 | defined eval f x inductively f where 33 | defined eval f x from f where 34 | defined eval (Num n) x = n 35 | defined eval Var x = x 36 | defined eval (Add f g) x = eval f x + eval g x 37 | defined eval (Mul f g) x = eval f x * eval g x 38 | defined eval (AfS f) x = eval f (S x) 39 | defined eval (Sum f) x = sumBelow (eval f) x 40 | 41 | diff :: Poly -> Poly 42 | defined diff f inductively f where 43 | defined diff f from f where 44 | defined diff (Num n) = Num Z 45 | defined diff Var = Num (S Z) 46 | defined diff (Add f g) = Add (diff f) (diff g) 47 | defined diff (Mul f g) = Add (Mul (diff f) g) (Mul (AfS f) (diff g)) 48 | defined diff (AfS f) = AfS (diff f) 49 | defined diff (Sum f) = f 50 | 51 | prove eval f x + eval (diff f) x = eval f (S x) inductively f where 52 | prove eval f x + eval (diff f) x = eval f (S x) from f where 53 | given f = Num n prove eval (Num n) x + eval (diff (Num n)) x = eval (Num n) (S x) ? 54 | given f = Var prove eval Var x + eval (diff Var) x = eval Var (S x) ? 55 | given f = Add g h prove eval (Add g h) x + eval (diff (Add g h)) x = eval (Add g h) (S x) test 56 | given f = Mul g h prove eval (Mul g h) x + eval (diff (Mul g h)) x = eval (Mul g h) (S x) test 57 | --------------------------------------------------------------------------------