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”

Default colormaps: Are Parula and Viridis really an improvement over Jet?

Jet was a ubiquitous colourmap that slowly fell out of fashion over the last five years. It was the default colourmap for Matlab and Matplotlib (and probably others) until 2015ish. The replacements, Parula and Viridis, respectively, get a lot of love. A quick Google search will present numerous blog posts and articles maligning Jet and promoting the use of these newer colourmaps. It’s an unpopular opinion but, especially now that they are common and overused, I dislike Parula and Viridis as much as I dislike Jet.

parula_viridis

Continue reading “Default colormaps: Are Parula and Viridis really an improvement over Jet?”

Python spoilt me, Part 2

In a previous post, I listed a range of Matlab’s idiosyncrasies and flaws that seemed so much more blatant once I returned from several years of Python use. This post is a continuation, except this time highlighting ways in which Python makes life simpler rather than Matlab making life more difficult.

If you haven’t tried Python and you’re on the fence about whether it’s worth learning, let the points below convince you.

Continue reading “Python spoilt me, Part 2”

This is the best decade to be a grad student

Catching up on the literature is a daunting aspect of graduate studies. As a physical oceanographer, I regularly cite work from 30 to 40 years ago. In that time, and all the way back to the turn of the 20th century, the scientists before me got to answer all the low-hanging-fruit problems and write the papers that will be cited thousands of time. They leave behind the messy, complex, and esoteric questions for the current grad students. Surely, then, I would think the 60s or 70s or even earlier would have been the best time to be a grad student?

Continue reading “This is the best decade to be a grad student”

An improved Matlab command line (plus Jupyter Notebooks for Matlab)

The command line is a large part of any Matlab user’s workflow. This vital tool, however, isn’t as user friendly as it should be: it’s cumbersome to recall multi-line commands from the history, there’s no support for Vim key bindings, and there’s no syntax highlighting if using the nodesktop option (on a remote computer, say). Fortunately, there’s an alternative that avoids these problems: IMatlab. This kernel also lets you run Matlab code in Jupyter Notebooks (originally known as IPython Notebooks).

Continue reading “An improved Matlab command line (plus Jupyter Notebooks for Matlab)”

Invest in a good text editor

Scientists should invest time in a good text editor: pay the upfront cost of learning to use and customising a single editor for all of your text needs. This may be obvious to programmers, but less so to scientists who may have yet to recognise the benefits of a good editor.

Much scientific analysis and documentation can be achieved with plain text files (e.g., .py, .m, .f, .r, .tex, or .md). The default method to work with multiple file types is to use multiple IDEs (Integrated Development Environments): Matlab for m-files, Spyder or IPython notebooks for python scripts, TexStudio or TeXnicCenter for latex files, RStudio for R, or one of the countless editors for Markdown currently available.

Using a single editor has many benefits over using a range of editors within each IDE:

Continue reading “Invest in a good text editor”