A better way to code up scientific figures

I typically write 100–200 lines of code each time I develop a scientific figure that is destined for publication. This is a dangerous length because it’s easy to create a functioning mess. With shorter code fragments, it’s feasible to start over from scratch, and with thousands of lines of code, it makes sense to invest time upfront to organise and plan. But in between these extremes lurks the appeal to write a script that feels coherent at the time, but just creates problems for future you.

Let’s say you want to create a moderately complicated figure like this:

A script for this figure could be envisaged as a series of sequential steps:

  1. Read data in from a csv file
  2. Remove any flagged data
  3. Create four subplots
  4. Plot the first line of data against time
  5. Label the y axis
  6. Set the y axis limit
  7. Repeat steps 4–6 for the second and third lines of data
  8. Add the coloured contours and grey contour lines
  9. Label the time axis
  10. Add various annotations
Continue reading “A better way to code up scientific figures”

Python spoilt me; returning to Matlab is hard

Using Python daily for more than three years as part of my scientific workflow and then abruptly returning to regular Matlab use has made me realise how much better Matlab could be and how evident its idiosyncrasies are. Conversely, while I was aware and noticed that Python makes things simple, it is Matlab’s comparative flaws that really made me come to appreciate just how much has been achieved in the past decade by the community in making Python an indispensable scientific tool.

An aim of this post is to recognize Python’s impressive convenience and versatility. Unfortunately, however, this post more naturally develops by taking the pessimistic approach of highlighting Matlab’s flaws. What follows are several minor, and a few major, annoyances that I’ve noticed on returning to Matlab.

Continue reading “Python spoilt me; returning to Matlab is hard”