Alex Lee and I are the joint winners of the 2024 Venables Award for new developers of open source software for data analytics! My submission was pypfilt, my Python package that implements various particle filter methods. Alex Lee's submission was whereabouts, a Python package for bulk geocoding and address standardisation.

This award is judged by the Statistical Computing and Visualisation section of the Statistical Society of Australia, and sponsored by the Australian Research Data Commons. Later this year we'll both appear in the ARDC's Shaping Research Software article series, and showcase our software packages in an SSA seminar.

It's a thrilling surprise and genuine honour to win this award. I'm looking forward to sharing thoughts and reflections on pypfilt and research software engineering in general, and in hearing about Alex Lee's work.

My biggest hope is that other people will find pypfilt useful for their own work 🤞🏼

In writing an R Markdown document to describe a within-host malaria model that I'm working on, I have focused on the HTML version of the document and made use of code folding to hide several code blocks by default.

The PDF version of the document includes the complete listing of each code block, but I instead wanted to remove the folded code blocks from the PDF version. And while it took me a long time to find a solution, the solution itself is quite simple.

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:

1. Being aware of the equivalence between two problems; and
2. Knowing how to solve (at least) one of these problems.

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.