In writing an R Markdown document to describe a within-host malaria model that I'm working on, I discovered that knitr::read_chunk() only accepts fixed line numbers and # ---- some-label marker comments.
So I've implemented read_function_chunks(), below, which extracts each top-level function as a separate chunk, and supports including roxygen documentation comments.
It's surprising how often you can translate one problem into another problem, for which there are known solutions and/or algorithms. For example, with Green's theorem you can choose between solving a line integral or a double integral, and select whichever option is simplest to solve. The necessary ingredients are:
One example that I found (by accident) was that preserving the connectivity of all placed tokens when upgrading a tile in an 18XX board game is equivalent to solving a maximum flow problem.
I've had a number of occasions to use my stochastic SIR demo since I first tested it out on a Melbourne Maths and Science Meetup audience, including last year's Communicable Diseases Control Conference in Canberra. I used it most recently in our school seminar on Wednesday 11 March, for which Jodie McVernon chose the title Model answers or trivial pursuits? Using epidemiological models to support COVID-19 preparedness and response. Jodie, Freya Shearer, and I talked about collaborative modelling efforts to better understand the transmissibility and severity of COVID-19, and how we had been using models to help identify effective and proportionate measures for health sector and whole-of-society responses. What a way to welcome our new head of school, Nancy Baxter!
There's been a huge amount of work done to date, by an ever-expanding network of collaborators. It has been genuinely rewarding to play a role in national and international efforts to respond to COVID-19, but it's also been extremely stressful and exhausting. And it's been terrifying to be intimately aware that my work is feeding into decision-making at the highest levels of government in the midst of an emerging global crisis. I am keenly looking forward to the day where our physical distancing measures have been relaxed and, in the company of close friends, I can look back at this time as something that happened to all of us.
Last night I gave a talk about Mathematical models of infectious disease transmission (slides) at the Melbourne Maths and Science Meetup. I used my stochastic SIR demo to simulate disease outbreaks amongst the audience — each audience member was assigned a unique number and had to stand up while they were infectious — and it's definitely something I'd like to try in a classroom setting. I was asked very good and challenging questions throughout the talk, and on several occasions my reply was "that's a great question, and I'll talk about that a bit later on". It was a fun night and a chance to meet some great people! Now I'm looking forward to being in the audience at their next event.
A steadily-increasing number of students and postdocs in our group find themselves needing to run huge numbers of model simulations, and the path of least resistance — using their local desktop or laptop — simply isn't feasible. Thankfully we have the Nectar Cloud at our disposal! I've been helping several people in our group transition to this platform, and this has prompted me to prepare several step-by-step tutorial for the different needs I've encountered so far. It's my intention to make these all available online, and the first cab off the rank is: How to create a MATLAB VM.
This semester I'm co-lecturing Declarative Programming (COMP90048). The topics I'll be covering include monads, laziness, performance, and type system expressiveness, with Haskell as our language of choice. This will be the first time that I'll try live coding in front of students, because I've previously lectured non-programming subjects such as multi-variable calculus and infectious disease modelling.
The obvious choice of tool for live demonstrations of Haskell code and expression evaluation is ghci. And I happen to have ghci already installed, by virtue of using xmonad to manage my windows and workspaces. I also spend most of my working hours living in Emacs, which has great support for working with interactive programming environments (also referred to as REPLs, Read-Eval-Print Loops) and for taking code blocks from open files and evaluating them in these environments. So I know what my preferred tools are. But it wasn't immediately clear to me what the precise workflow should be.
"It is difficult to make predictions, especially about the future" — this famous quote is a great opening line when discussing infectious disease forecasting. I used it in my talk at the Australian Influenza Symposium (1-2 Nov 2017), as did a speaker in an earlier session. And there are many reasons why infectious disease forecasting is hard. There isn't a single-biggest roadblock to making accurate epidemic forecasts, and I was recently quoted about this very matter in "How Bad Will the Flu Season Get? Forecasters Are Competing to Figure it Out" (The Scientist, 28 Nov 2017).
I really enjoy the challenge of engaging with non-academic audiences, both as an end in itself, and also because it should help me improve my grant writing. And this isn't my first experience with the media. I've previously been quoted in articles about the link between climate and influenza transmission (Flu outbreaks are subject to humidity — not just heat, Cosmos, 1 Nov 2016), and our collaboration with the Victorian Department of Health and Human Services (Defence scientists' bio attack detector could predict flu outbreaks, Herald Sun, 14 Jul 2016).
Infectious disease forecasting has been a very active research area in the past few years, and these methods have the potential to provide valuable decision-support capabilities for public health staff. There are many challenges that must be surmounted before this can be realised, and one major gap in the literature is operational research in pilot, real-world applications. We report on exactly this kind of study in our most recent forecasting paper, "Epidemic forecasts as a tool for public health: interpretation and (re)calibration", which has just been made available online and will appear in an upcoming issue of the Australian and New Zealand Journal of Public Health.
In thinking about the strengths and limitations of different surveillance systems — from the perspective of infectious disease forecasting in my case, but the point applies more generally — it becomes clear that there is no silver bullet. No one surveillance system will tell us everything we need to know in order to understand the current impact of a disease on a population, or to predict the future impact of a disease. The surveillance pyramid model illustrates this in a very nice and clear manner:
I've been learning a bit of Rust in the past few weeks, mostly by writing some basic SIR-type models (both as ODE systems, and as continuous-time and discrete-time Markov chains). It takes most (maybe all) of the things that I like about OCaml and adds more great features and safety guarantees, thanks to its ownership model and lifetimes. It's also very fast (no garbage collector, zero-cost abstractions) and has fantastic tooling, although compilation times can be very long, and package ("crate") availability can be very hit-or-miss. I've enjoyed it enough that I'm looking forward to writing more Rust code in the future. Although I've no plans to rewrite pypfilt or epifx in Rust any time soon!