The recent preprint ‘You need 27 tickets to guarantee a win on the UK National Lottery‘ by David Cushing and David I. Stewart presents a list of 27 lottery tickets which will guarantee to match at least two numbers on the UK National Lottery, along with a proof that this is the minimum number you need to buy. The argument is clever and makes delightful use of the Fano plane.
I wrote some Python code that runs all 45,057,474 possible draws against these 27 tickets.
All draws had between 1 and 9 winning tickets from the set (crucially, none had zero!). Obviously for 27 of the draws one of the winning tickets matched all six numbers, but about 75% of the draws saw a maximum of 2 balls matched by the winning tickets, and a further 23.5% had at most 3 balls matched. This means almost 99% of the time the 27 tickets match just two or three balls, earning prizes which may not exceed the cost of the 27 tickets! (I recommend reading Remark 1.2 in the paper.)
More findings and my code on GitHub.
Update 1: Tom Briggs asked what’s the expected return for buying these 27 tickets. I think the average return is about £20, which is a £34 loss (and of course this is an average from a set of numbers that includes some big wins). Assumptions and details in the GitHub.
Update 2: Matt Parker prompted me to investigate what percentage of draws end in profit. Even though 99% of the time the tickets match just two or three balls, if more than one ticket matches three balls that would still be a small profit. In fact, a profit is returned in 5% of draws, though as noted above the expected return is a loss. Matt included this result in a fun video about the 27 tickets. Again, assumptions and details in the GitHub.
When teaching moved online due to COVID-19, we had to quickly work out how to deliver our modules online. The main options used to replace in-person classes were:
- pre-recorded videos followed by live online tutorials for students to get support while completing exercises;
- live online classes offering a mixture of lecturer delivery and student activity.
The first option is good for a module with lots of content delivery, such as when learning new mathematical techniques. In modules with some content delivery but a focus on interaction and discussion, such as mathematical modelling, the second is a good choice.
I felt neither was quite right for my second-year programming module. I opted instead for delivering notes and exercises which students could work through when convenient (which might be in a designed class time or might not) and used my time on the module to write responses to student queries and give feedback on programs written as formative work.
In class students tend to say they’ve done an exercise correctly and because you’re walking round a computer room it can be hard to examine their code in detail. Spending time looking at what they submit as ‘correct’ code in greater detail, it became clear that often there are subtle issues which can be usefully discussed in considered feedback.
Overall, I think this semi-asynchronous delivery was much better use of time and I was able to view more code and give better feedback than I would in-person.
I wrote about my experience delivering this module through the pandemic – the end of one academic year and the whole of the next – with Alex Corner in an open-access article which has just been published as ‘Flexible, student-centred remote learning for programming skills development‘.
This is part of a special issue of International Journal of Mathematical Education in Science and Technology – Takeaways from teaching through a global pandemic – practical examples of lasting value in tertiary mathematics education. There are loads of articles with useful reflections and good ideas that emerged from pandemic teaching.
If you are interested in pandemic literature in higher education teaching and learning, I’m aware of two other journal special issues you might like:
This is a guest post by semi-regular guest author, mathematician-turned-maths-teacher Andrew Stacey.
I like having something mathematical to think about for times when I’m, for example, waiting in a queue to get into the supermarket. Annie Perkin’s Math Art Challenge has been a good source of such of late. These are a series of mathematically-inspired artistic activities, ranging from designing celtic knots to constructing origami polyhedra and everything in between.
My eye was caught by one on sandpiles – I’ll explain exactly what they are in a moment. One feature that made it attractive was that it was quite simple to write a program to generate diagrams. I find that the maths that interests me usually comes from looking at variations, and for that I need to generate a lot of examples. Doing them by hand quickly becomes laborious. So I whipped up a program (which I later converted to an online version) and ran it a few times to see what happened.
This week, Katie and Paul are blogging from the Heidelberg Laureate Forum – a week-long maths conference where current young researchers in maths and computer science can meet and hear talks by top-level prize-winning researchers. For more information about the HLF, visit the Heidelberg Laureate Forum website.
Image: Heidelberg Laureate Forum Foundation / © Bernhard Kreutzer
At last year’s HLF, Turing Award Leslie Lamport gave us his (not wholly complimentary) thoughts on the state of proof-writing in mathematics. Since he has worked in both maths and computer science, members of the latter discipline may have felt they got off quite lightly. Perhaps to redress the balance, this year we found out what he thinks is wrong with most people’s code and algorithms, in a talk titled If You’re Not Writing a Program, Don’t Use a Programming Language.
Here are three things we noticed this month which didn’t get a proper write-up, due to thesis/Edinburgh fringe/holidays: a big proof, a fun maths book club, and a ridiculous bit of pi-related madhattery.
Mathematical and statistical software specialists The Numerical Algorithms Group (NAG) are advertising a twelve month student placement in Oxford as a software engineer.
We are looking for somebody who has completed the equivalent of two years of a three-year degree course. A strong computing component in the course is important and some mathematical background or experience using software to solve scientific or engineering problems would be a big advantage. The ideal candidate should have experience of programming in a Windows, Unix or Linux environment. Some knowledge of C or Fortran would be useful, but is not essential.
The deadline is 31st January 2013.
Further details: Student Placement: Software Engineer.
via Mike Croucher on Twitter.
Google Code, one of now approximately a million different websites which start with the word Google, is a sharing platform for developers to exchange open-source programs and nifty things they have made.
One such nifty thing is this Reaction-Diffusion package, based on our old friend Alan Turing’s famous equation. The reaction-diffusion equation, originally given in Turing’s 1952 paper The Chemical Basis of Morphogenesis, provides a model for how a mixture of chemicals, reacting with each other while moving under the action of diffusion, might result in the kind of patterns we see in animal print and elsewhere in nature.