Posts | Roy Goodman

How should we LaTeX?

Fri, 02 Jul 2021 22:22:55 -0400

TL;DR: Start from , then read the style guide below.

Last updated October 2026. I first wrote this post in 2021 around the physics package. That package hasn’t been updated since 2012 and has some , so I now recommend two maintained replacements: physics2 (delimiters, bra–ket notation, matrices) and derivative (derivatives and differentials).

$\LaTeX$ can be intimidating for students who are just learning it, but never fear: this document will help. If we’re going to publish something together, it will eventually have to meet my standards. By following this document, you’ll learn my approach to writing in $\LaTeX$ and hopefully avoid having to do things twice.

Some ideas from this document were taken from other documents I found on the web such as from Stephen Boyd at Stanford, from Neil Lawrence at Cambridge, and from Robert Dale at Macquarie. I started writing this thinking it was a guide to help students do things my way, but in the process of getting my thoughts down, I had to look things up. I learned a few things that I will be adopting in my own writing.

Basic principles

In my mind, there are two basic principles in writing good $\LaTeX$.

Separate meaning from formatting
Use packages and class files written by other people.

These two principles are related.

Separating meaning from formatting

My limited understanding of the history is that Knuth created $\TeX$ to enable computers to typeset mathematics and to do so consistently regardless of the computer being used. Lamport then built $\LaTeX$ on top of Knuth’s foundation in order to separate presentation from content. A primary example is given by the way fractions are represented in the two systems. In $\TeX$, the fraction $\frac12$ is written as ${1}\over{2}$ . That is a typesetting command: it states that the numeral “one” is placed “over” the numeral “two.” While most plain $\TeX$ code is still legal in $\LaTeX$, in the latter system the preferred form is $\frac{1}{2}$ which is easier for a human reader to interpret as a fraction.

Well-constructed $\LaTeX$ should be easy to read, and should be focused on representing meaning, not simply formatting.

Macros

Good $\LaTeX$ writing should make extensive use of macros. In writing computer programs, whenever there is a piece of code that gets re-used multiple times and accomplishes a specific task, it makes sense to define a function and to call that function each time you need to accomplish that task. In writing $\LaTeX$, the equivalent idea is to use macros to replace frequently used snippets. There are a number of important reasons for this (how we do so will be discussed later):

Macros help you to encode meaning rather than typesetting instructions. For example the absolute value of $x$ should appear as $\abs{x}$ , not as $|x|$ . (See below for two good ways to define \abs.)
Long strings of typesetting are hard for you to parse and to type exactly the same every time. Suppose you define a complicated mathematical object that you decide to name ${{\mathcal C}^\infty_{\mathrm{c}}}$. Do you want to type {\mathcal C}^\infty_{\mathrm{c}} every time you use it and have to have that expression repeatedly taking up half a line of your .tex document? Or would you rather define a macro \CIc that you can use repeatedly?
Macros make it easier to change the document. Suppose that you decide instead to change your notation to ${{\mathfrak C}^\infty_{\mathrm{c}}}$. If you define a macro, you change it once and the change appears everywhere. Otherwise, you have to carefully comb through your document to find every occurrence of this expression.

In general, if you are trying to typeset a common mathematical function, such as a derivative, norm, or absolute value, you should find a package that contains the macro you need. If, on the other hand, your paper contains a vector-valued variable named $\mathbf{p}$, you should define a macro, rather than typing \mathbf{p} dozens of times.

I have used four methods to declare macros:

\newcommand can take arguments. Examples:
- \newcommand{\p}{\mathbf{p}} Now you can type $\p$ to get $\mathbf{p}$.
- \newcommand{\CIc}{{\mathcal C}^\infty_{\mathrm{c}}} for the above example
- \newcommand{\diff}[2]{\frac{d #1}{d #2}} defines a basic derivative macro. Example: \diff{y}{x} would give $\frac{dy}{dx}$. (Better: use \odv from the derivative package.)
\renewcommand is just like \newcommand but you use it if the command you want to assign is already assigned to something else.
\DeclareMathOperator (requires the amsmath package; note the capitalization). You’ll note that functions such as sine and cosine are written in Roman characters and are defined as operators, which affects the spacing between them and their argument. For example the standard way to write $\sin{\theta}$ is \sin{\theta}. However there’s no hyperbolic secant built in so you could define \DeclareMathOperator{\sech}{sech}, which you’d call using \sech{x}.
\DeclarePairedDelimiter (from mathtools). Here is how my approach to absolute values has evolved:
1. Basic: |x|. The bars don’t grow to fit tall contents such as fractions, and the code says nothing about what the bars mean.
2. Better: a macro built with mathtools: \DeclarePairedDelimiter{\abs}{\lvert}{\rvert}. Now \abs{x} says what you mean, and \abs*{\frac{p(x)}{q(x)}} (with the star) scales the bars to fit.
3. Also good: the physics2 package’s \ab command (from its ab module; see below) sizes any pair of delimiters automatically: \ab|\frac{p(x)}{q(x)}| gives $\left\lvert \frac{p(x)}{q(x)} \right\rvert$, and \ab*|x| turns the sizing off. To keep the meaning in your source, wrap it in a macro: \newcommand{\abs}[1]{\ab|#1|}.
The same tools handle other paired delimiters. For an inner product, either define \DeclarePairedDelimiterX{\innerp}[2]{\langle}{\rangle}{#1,#2} so that \innerp*{\frac{p}{q}}{f} gives $\left\langle \frac{p}{q},f \right\rangle$, or write \ab<\frac{p}{q}, f> with the ab module of physics2. Bonus tip: use \langle and \rangle, not < and >, for inner products.

Using packages

Here are the packages that are called in my template. In some cases, the order they’re called matters, as package B may depend on package A. Each is fully documented, so I’ll just say why I like it and the major ways I use it.

Fixing outdated things about $\LaTeX$

csquotes is a sophisticated package for handling quotes that does lots of things. I use it to do one thing. In order to get nice curly quotation marks like “Happy Birthday” in $\LaTeX$ you have to write ``Happy Birthday'' with two single left-hand quotes on the left and two single right-hand quotes on the right. The package allows you to use plain old straight quotes like "Happy Birthday" and still get curly quotes.
```
\usepackage{csquotes}
\MakeOuterQuote{"}
```
Accented characters (inputenc and fontenc). When $\LaTeX$ was written, computers had access to a much smaller character set and could not natively display accented characters like é, ñ, ö, so you had to enter these as \'{e}, \~{n}, and \"{o}. A more modern character-encoding standard is UTF-8. Since 2018, $\LaTeX$ reads UTF-8 input by default, so you can type Schrödinger and Poincaré directly; the old \usepackage[utf8]{inputenc} line is no longer needed (it’s harmless if you keep it). Your file does need to be saved as UTF-8: Overleaf does this automatically, and in TeXShop you can set it in the preferences or add the line % !TEX encoding = UTF-8 Unicode at the top of the main .tex file. Separately, load fontenc so that accented words hyphenate properly and copy correctly from the PDF:
```
\usepackage[T1]{fontenc}
```
These are packages from the American Mathematical Society that have lots of features that make writing math easier and better: from their names, you can guess that they introduce (i) general math stuff, (ii) environments for defining theorems, and (iii) additional math symbols. It’s worth reading the documentation to learn all the features. When I was writing my dissertation, the postdoc in the next office told me to stop using the eqnarray environment and to learn about the equation alignment features. He was right. Other important features:
- Use the AMS defined \eqref command to reference equations rather than the basic \ref. This puts parentheses around each reference.
- \DeclareMathOperator as described above
- a cases environment
- the pmatrix and bmatrix environments are the standard way to define matrices.
- the \text command for text in the middle of an equation. To get \[ a = b \quad \text{and} \quad c=d \] write a = b \quad \text{and} \quad c=d. If you do this often, define a macro such as \newcommand{\qand}{\quad\text{and}\quad} and write a = b \qand c = d.
mathtools builds on top of the AMS packages. It provides the \DeclarePairedDelimiter construct I used to build the absolute value and inner product macros. Another useful command: regular $\LaTeX$ renders := with poor vertical alignment. mathtools provides \coloneqq, which fixes this.
physics2 is a modern, maintained replacement for the old physics package. Loading the package by itself gives you almost nothing: each feature lives in a module that you must enable with \usephysicsmodule, after \usepackage{physics2}. List only the modules you need, separated by commas:
```
\usepackage{physics2}
\usephysicsmodule{ab,ab.braket,diagmat,xmat}
```
- ab module: the \ab command, which sizes a pair of delimiters automatically: \ab(\frac{x}{2}), \ab[\dots], \ab\{\dots\}, \ab|x|, \ab\|x\|, and \ab<f, g>. Use it for function arguments too, as in \sin\ab(\frac{x}{2}). A star, \ab*|x|, turns the automatic sizing off.
- ab.braket module: Dirac notation with \bra<\phi|, \ket|\psi>, \braket<\phi|A|\psi>, and \ketbra.
- diagmat module: diagonal matrices, e.g. \pdiagmat{1,2,3} for a diagonal matrix in parentheses.
- xmat module: matrices with patterned entries, e.g. \bxmat{a}{3}{3} for a $3\times3$ matrix with entries $a_{ij}$ in brackets.
- doubleprod module: the double-dot and double-cross products used with tensors.
derivative handles derivatives and differentials, with many options for order and style.
- \odv{y}{x} gives an ordinary derivative, \odv[order=2]{y}{x} a second derivative, \pdv{f}{x,y} a mixed partial derivative, and \fdv{F}{u} a functional derivative.
- \odif{x} gives the upright $\mathrm{d}x$ in an integral, with the right spacing: \int_0^1 f(x) \odif{x}.
natbib is a package for working with BibTeX. In particular calling the command as
```
\usepackage[numbers,sort&compress]{natbib}
```
turns a citation that would have rendered as $[6,1,2]$ into $[1,2,6]$, and turns $[1,2,3,4]$ into $[1-4]$. Saves space and looks better!
breqn breaks long displayed equations across lines automatically, and allows matched delimiters such as \left( and \right) to match across line breaks. It can clash with other packages, so load it last and remove it if you see strange errors.
fullpage reduces margins so that you can see what you’re writing.
todonotes does two things: (1) allows you to create to-do items and list them at the front of the document and (2) creates placeholders for figures that aren’t ready yet.
showlabels shows the labels next to equations and figures so it’s easier to recall their names when you want to reference them.

My style guide

Some reasons to have a style guide are for consistency and to conform to professional conventions. On top of that, poor style can be distracting to the reader. I learned a bunch of things while preparing this document, so this style guide represents how I intend to use $\LaTeX$ in the future, rather than how I have always used it.

This is a hard one. $...$ and $$...$$ are plain $\TeX$. The $\LaTeX$ equivalents are  and \[ \]. Does this make a difference? I don’t know, but it’s and is supposed to improve spacing before and after equations, so I’m going to try to do it from now on. You can download a python script called that will convert this for you.
Vectors: bold, usually lowercase. Don’t use arrows. Use \mathbf{v} for Latin letters, and \bm{\xi} from the bm package for Greek letters (or \bm for everything, if you prefer bold italic). Define a macro for each vector you use.
Matrices: Uppercase, bold.
Derivatives: Use the \odv command from the derivative package, \pdv for partials and \fdv for functional or Fréchet derivatives.
The $\mathrm{d}$ in an integral is typeset using the \odif{x} command from the derivative package. This will automatically handle the spacing before the letter.
Bibliography & References:
- Use BibTeX. This is one area where I have especially strong opinions. Specific guidelines:
  - BibTeX is reusable between documents. Reuse prevents new mistakes. Try to download the BibTeX from the journal’s website for an article rather than entering by hand, e.g., click on the “download citation” button .
  - While a BibTeX file is plain text, it’s better not to have to edit it directly. Even if you use Overleaf, I find it preferable to edit on my own computer using the BibDesk app. That way I don’t mess up all the brackets.
  - Use the appropriate document type.
  - Make sure that letters in article titles that must stay capitalized (proper nouns, e.g., {S}chrödinger) are surrounded by {}. Otherwise they’ll get converted to lowercase.
  - Author names should be consistent. First and middle names should be shortened to initials. You don’t have to actually edit the BibTeX file. Choose a bibliography style that automatically abbreviates for you, such as \bibliographystyle{abbrv}.
  - Leave the “number” field and the “month” field blank.
- Use \eqref to reference equations. Use a nonbreaking space (denoted with a ~) before the reference commands \ref, \eqref, and \cite. For example A graph of Eq.~\eqref{equation1} is shown in Fig.~\ref{thisfigure}.
- The words Figure and Equation should always be abbreviated in references. As above, the word “Fig.” should always appear before a figure reference. Referenced equation numbers should always be preceded by a word: usually “Eq.” but sometimes it’s more natural to say something like “Inequality (5)” or “Hamiltonian (6)”.
If a word appears in a subscript or superscript, it should be in Roman script. $X_{\mathrm{max}}$ not $X_{max}$, written as $X_{\mathrm{max}}$ . Make a macro \Xmax and call that.
Use “we,” not “I.” Mathematical writing conventionally uses “we” to bring the reader along (“we now show that…”). Prefer it to the passive voice, which tends to hide who is doing what (“it is shown that…”).
Equations are part of sentences and need to be punctuated.
Don’t start a sentence with a symbol. Say “The norm $\lVert x\rVert$ is finite,” not “$\lVert x\rVert$ is finite.”
Let $\TeX$ do the spacing. If you’re reaching for \, or \;, the real fix is usually to tell $\TeX$ what the symbol is: \{x \mid x>0\}, not \{x \;|\; x>0\}; f \colon X \to Y, not f:X\to Y; \DeclareMathOperator{\tr}{tr}, not \mathrm{tr}\,A. Hand-spacing belongs in only a few places: \quad before a side condition (f(x)=0, \quad x>0), ~ before references and citations, and \ (backslash-space) after a period that doesn’t end a sentence (e.g.\ , et al.\ ). When you inherit a file full of hand-spacing, delete it all, recompile, and add back only what visibly needs fixing.
Figures:
- If making figures in MATLAB, use my startup.m file to get better defaults, in particular thicker lines, larger text in labels, and the $\LaTeX$ interpreter in all text. Thin lines disappear, especially when projected as slides.
- Don’t ever use the MATLAB green represented by 'g'. Especially not in talks. It shows up very poorly on the screen.
- Align subfigures and avoid too much whitespace between and around them.
- Don’t get me started on colormaps! The old default MATLAB colormap, called jet, used in commands like pcolor and surf is bad, bad, bad and should never be used. The new default colormap parula is better but still not optimal. A lot of perceptual research has gone into the design of the colormaps for the Python library matplotlib and has been ported over to . The link contains a video with an explanation.
- The document recommends against using the \begin{center}...\end{center} syntax in a figure; use \centering instead, i.e.
```
\begin{figure}
\centering
\includegraphics{imagename}
\end{figure}
```
  is preferred over
```
\begin{figure}
\begin{center}
\includegraphics{imagename}
\end{center}
\end{figure}
```

Getting help

In TeXShop on a Mac, under help, click on “Show help on package” and enter the name of a package to read more about it.
If you are running $\LaTeX$ on a Mac, you most likely have a program installed called TeX Live Utility. It has three tabs. The first allows you to keep your $\TeX$ installation up to date. It usually takes a minute to load while it checks for all the updates. The second tab “Packages” contains a list of all the installed packages. You can search for useful installed packages. For example, search for “Exam” and you’ll find the Exam package, which is the right way to write an exam. (I have never clicked on the third tab “Backups”)
Google “How do I … in LaTeX?” This will usually take you to a discussion on the . Somebody has already asked the thing you want to know.

Overleaf

Do not email documents back and forth. Do not create a sequence of documents named document1.tex, document2.tex, etc. This can only lead to mistakes. Online tools such as handle shared documents much more elegantly.

If you prefer to edit locally, then set up Dropbox integration under Account $\rightarrow$ Account settings on Overleaf. Edit on your personal device. Syncing isn’t instantaneous, but it prevents versioning hell. Sadly, this requires a premium or institutional Overleaf account.

My template and abbreviations files

At there are three $\LaTeX$ files: a master template file and two include files, one containing all the packages I use and the other containing the macros. I have also included a startup.m file for MATLAB. It should go in the search path and will run automatically when MATLAB starts. This changes the behavior of MATLAB’s text annotation functions such as xlabel and title. Any math that appears in such a command must now be enclosed in dollar signs, such as in xlabel('$\omega$'). This allows for both better looking text in your figures and opens up the possibility of much more complex math in the labels.

matdfield & matpplane (2021, now superseded)

Tue, 02 Feb 2021 22:06:58 -0500

Note

Use these instead: . I’m happy to report that my work here has been rendered obsolete. Brian Hong at MathWorks has written new programs that are sleek, modern, documented, and in every way superior. The rest of this post describes my 2021 update of the old programs and is kept for the record.

I have written a new front end and made many, many fixes to the old MATLAB programs dfield and pplane that make them compatible with MATLAB Release 2020b. To distinguish these new working programs, I’ve renamed them:

matdfield draws direction fields for (possibly nonautonomous) first-order scalar ordinary differential equations.

matpplane draws phase plane portraits for autonomous first-order systems of two ordinary differential equations.

I’ve also created a simple launcher packaged as a MATLAB App, so all a student needs to do is click a button.

The best place to download them is the .

They have lots of nice features:

drawing level sets
finding equilibria and linearizing about them.
finding stable & unstable manifolds
saving user generated equation definitions to files and galleries.

These programs were originally copyrighted by John Polking between 1995 and 2003. The textbook Ordinary Differential Equations Using MATLAB, 3rd edition, contains a manual for the programs, but they are pretty self-explanatory.

The codes were last properly updated in 2003 for MATLAB 6.5. The MATLAB File Exchange contains many submissions that got the codes running again on some release or other, but none that systematically attempted to fix all the broken components.

I have tried to fix all the errors but have not managed to fix everything. I have examined every warning produced by the Code Compatibility Report and the Code Analyzer Report features in MATLAB. I have been able to fix almost all of these. Where I could not, I suppressed the warning and left a comment. Most of the remaining warnings are due to arrays that change size over iterations, and there’s not much to do about them. Many came from an overuse of the eval and feval commands, which I have replaced by more modern coding constructs.

As far as I can tell everything works except for:

The ‘Revert’ button
The ‘Zoom Back’ feature in pplane (works in dfield, should be able to fix in pplane).
“Find a nearly closed orbit” in pplane.
The message section at the bottom of the display is garbled in pplane (again, it works in dfield so should be fixable.)
Certain forms of complicated ODE cause crashes.

Under the hood, the program is a mess. There is a lot I would like to fix, but the structure of the original function would make modernization nearly impossible.

Each program (pplane & dfield) uses a structure where each callback, instead of being a separate function, is given by a recursive call to the main program (matdfield) or (matpplane), determined by a very long if-then-else structure. I have tried breaking out the contents of individual elseif blocks into separate functions, in their own m-files. This has generally led to strange and hard-to-trace errors, so I abandoned the effort. This structure makes understanding the scope of variables very challenging.
The function of each elseif block is rarely documented, although I added some documentation in my attempt to understand what each does.
A lot of code is dedicated to fiddling with window dimensions and similar display issues. The variable names used to do this are not self-explanatory and contain lots of magic numbers.
A lot of code is dedicated to string manipulation. Either this was written before MATLAB added straightforward string-handling features, or else the authors didn’t know about these features. To be fair, the original programs were written before Google existed(!), so discovering MATLAB functionality would have involved searching in books!
There are a lot of calls to eval and feval which leads to hard-to-decipher codes. I have corrected this in the cases where such constructions confused the Code Analyzer.

Nonetheless, there are a lot of simple cleanups that might make this more maintainable, including lots of repeated code that should be moved to separate m-files and made into functions. I will continue to maintain this code and make sure that it remains compatible with future MATLAB releases. If anyone would like to help out, or finds an error they’d like to fix, the code is available on . Any other bugs you find, please let me know.

Acknowledgments: The current codes are based on revisions by Nathanael Kazmierczak (pplane) and Giampiero Campa (dfield). I gratefully acknowledge their efforts and those of others who posted fixes to the MATLAB File Exchange. Several other people sent me partially working codes including Mac Hyman, Hil Meijer, Joceline Lega, Ross Parker, and Björn Sandstede. I got lots of help by posting questions to MATLAB Answers. These were usually answered (within minutes) by Walter Roberson, of MathWorks. Div Tiwari, also of MathWorks, provided additional useful suggestions.

Summary of Responses to my post to the SIAG-DS mailing list

Tue, 02 Feb 2021 22:05:43 -0500

Note

Written in January 2021. Several of the tools below have changed since then, and the best option for MATLAB users is now .

The email

On January 5 I sent to the SIAG-DS mailing list about the old MATLAB programs dfield and pplane. I posted the same question to the Facebook group STEM faculty blundering through remote teaching in a pandemic. My goal was to see if I could get the programs running again to use in my undergrad ODE classes, and, in the longer term, to rewrite them from scratch.

The responses

Over the next two weeks I received about 30 response emails. I learned a lot from these emails and I thought the best thing I could do is share them.

The main thing I learned is that a lot of people still like these programs and would like to be able to use them. A second thing I learned is that lots of people have managed to fix just enough bugs to keep the program hobbling along. A few people have uploaded these partial fixes but nobody, as far as I was able to tell, had made an attempt to systematically go through the code and fix everything. One person who had made some fixes, and had the forethought to take notes on it as he went, is Nathanael Kazmierczak, now a grad student at Caltech. He sent me his updates and his notes, and patiently answered my questions via email. I decided to run this code, “push all the buttons,” and try to fix all the errors. I believe I have done this. Also, I hereby appoint myself maintainer of these codes for the near future or until we can get something better in MATLAB.

My requirements

Lots of people wrote me to tell me about other options for graphing direction fields and phase planes and more. I knew about a lot of these and have even used a few of them myself for research and teaching. In my opinion, none of them suits my particular needs as well as dfield and pplane, which meet three requirements:

It should be in MATLAB. Our undergrads use MATLAB throughout the curriculum. Using dfield and pplane allows me to assign as the first assignment: get MATLAB running and run this pre-written program, without asking students to learn any programming.
It should be really, really simple. Our 200-level ODE course typically runs 10 sections and 300 students per semester, many taught by adjuncts and lecturers, who aren’t necessarily experts in programming. Many of the students have just transferred from two-year colleges that don’t use MATLAB as much as we do. I just want it to work.
It should have a GUI.

Other options

I’ll arrange these by suitable audience and purpose:

Dfield/pplane equivalents

Good for teaching undergraduates

This is a terrific app for iOS and Android devices, written by a group of students and faculty at Pepperdine University led by Timothy Lucas. It is great to use on an iPad during remote lectures and the graphics are stunning compared to pplane and dfield. The Android version is new and not yet full-featured. I don’t think that robust numerical libraries for these devices exist, so they have had to write a lot of the numerical guts of the code themselves. As such, I have managed to break the code on several occasions while trying out exercises and examples I wanted to use. Tim has been very responsive to my inquiries and is aware of the issues.
Authorized clone of the original dfield/pplane programs. Requires a Java Runtime Environment. Works fine, bad graphics export.
An open-source reimplementation of pplane and dfield written in Python. It appears to be under active development but to run it on Mac or Windows, you need to clone a GitHub repo, so that’s too hard for a big undergraduate class. Someday there may be binaries…
On the webpage of Darryl Nester of Bluffton University, h/t
From the LibreTexts free textbook website. h/t
an R package for exploring one and two dimensional autonomous ODE systems, by Michael Grayling et al. Not a GUI, so not for an intro class. h/t .

Writing your own

has a basic equivalent of dfield on his
shared some codes with me. I didn’t get his permission to share them, but what impressed me was that the documentation was many times longer than the codes themselves. I commented on how thoughtfully done this was and he responded, “As to documentation, this is something I place a premium on, also in my development of more sophisticated tools. I have often found that it actually helps tighten up the software implementation as well, especially when a mathematical notation and a logical flow can be developed in parallel with the encoding and both made to mirror one another.”
is using for a similar purpose, with what sounds like significant technical support from Brown University.
Beyond heavy reliance on the Slopes app, I made extensive use of MATLAB Live Scripts the last time I taught out of Strogatz’s book. I wanted to show how, with today’s tools, it is straightforward to reproduce all the classical results Strogatz discusses and introduce students to the interplay between theoretical and numerical studies that leads to insights. I ended up writing something of a .

More Advanced Students and Research

I like these but they don’t fit the bill for big intro classes. These are just the ideas people sent me. For a more complete list, look at the at DSWeb, h/t Andrew Bernoff.

MATLAB package for continuation and bifurcation in discrete and continuous systems. I have used this in my own research and in a graduate class. Highly recommended.
I’ve been meaning to learn Julia for years! Somehow it always seems easier to stick with MATLAB. In particular, Isaia Nisoli pointed out .
from Nick Trefethen and company in Oxford.
is a nice program that is no longer in active development, h/t John Tyson
, from Stuart Heitmann, is an open MATLAB toolbox for simulating dynamical systems and plotting phase planes etc. It was designed for computational neuroscience but can be applied to dynamical systems in any domain (ODEs, SDEs, DDEs, PDEs). Students can implement their own models (often less than 100 lines of code) and run them in the graphical interface without any graphical programming effort. The latest version uses the modern MATLAB uitools graphical interface. It requires MATLAB R2019b or newer.
from Bard Ermentrout remains very popular.

Posts | Roy Goodman

How should we LaTeX?

Basic principles

Separating meaning from formatting

Macros

Using packages

Fixing outdated things about \(\LaTeX\)

My style guide

Getting help

Overleaf

My template and abbreviations files

matdfield & matpplane (2021, now superseded)

Summary of Responses to my post to the SIAG-DS mailing list

The email

The responses

My requirements

Other options

Dfield/pplane equivalents

Writing your own

More Advanced Students and Research