As I mentioned in Moving, Fast and Slow, @dspivak and I are working on a little physics engine, to try and work out what a compositional theory of physics based on polynomial functors would look like.
We started out by making a very simple system where a ball collides with different surfaces. However, something funny happened! We noticed that over time, the ball bounced higher and higher! In order to investigate why this was happening, we displayed the total (kinetic + potential) energy of the ball in the corner of the screen, and after remembering that you have to multiply mv^2 by \frac{1}{2}, we saw that the total energy was slowly but steadily increasing over time! This told us that it wasn’t an error with our collision code, it was an error with our basic update.
It was at this point that I remembered something I heard a while ago, which is that you should stagger the update of position and velocity. So instead of
it should be
Sure enough, once we implemented this the total energy remained roughly constant, and more importantly, it fluctuated both up and down slightly rather than only fluctuating up, so it was approximately conserved over a much longer time period.
It was such a cool experience to be able to just see with my eyes the effect of numerical instability, and then also see that the fix actually worked! While I abstractly “knew” that staggering the updates was the right thing to do, it’s a totally different thing to have practical experience of it.
I think this shows how important playing around with computer implementation is to understanding of mathematics. It’s one thing to have some abstract idea on the whiteboard, but it’s not really “real” until you can see it in action on a computer. I encourage you, even if you don’t consider yourself a programmer, to play around with your ideas in a programming language, even if you don’t think the resulting software will be useful for anyone, just because you’ll learn things you didn’t expect.