Procedural approach to classical mechanics

Physics notation is often ambiguous. Unstated notational conventions are effective tools if the context is clear. However, a formal definition of procedures about how to automatically compute (as by a computer) a given quantity requires unequivocal syntax.

As an example, let's consider Euler-Lagrange equations. In the traditional notation they read:

A dumb computer will have issues in accepting the above notation:

• We think of coordinates \(q^i\) and velocities \(\dot{q}^i\) as independent when taking partial derivatives. But we also now that \(\frac{d}{dt} q^i = \dot{q}^i\): here the interpretation changes and positions and velocities are not independent.
• It contains an obvious typo: the Lagrangian (and its partial derivatives) is a function of multiple variables, but \(d/dt\) only applies to functions of one variable.

The above notation works with the implicit assumption that we mean to substitute the path and its derivative (both are functions of time, so that the total time derivative makes sense) into the coordinate and velocity arguments of the partial derivative functions. If \(w^i\) is a path through the coordinate configuration space, then

The use of ambiguous notation is convenient in this simple case. Still, implicit and equivocal mathematical notation is an obstacle to interpret the equation above programmatically.

M. Spivak in Calculus on Manifolds argues in favor of a functional notation. For instance, the chain rule would read \(D(f \circ g) = ((Df) \circ g) \cdot Dg\), so at \(a\):

Given the proper basic symbols definitions, this expression is unequivocal and it does not require the introduction of irrelevant letters (as is the case of the traditional notation).

The main advantage of functional notation over traditional notation is that it is well adapted to be interpreted automatically, independently from the context. Programming languages cannot deal in a robust, general way with apparent contradicting statements that a human would know how to interpret given the context. (There are exceptions, though. See for instance the prototypical language discussed in G. J. Sussman and A. Radul, The Art of the Propagator, 2009.)

The procedures formalized in the examples above are robust, i.e., not bound to a specific context. The Euler-Lagrange equations procedure generalizes automatically to arbitrary Lagrangians or coordinate paths. It can be composed with other arbitrary functions, too (as long as their domains overlap).

The procedural syntax used in the examples is the Scheme dialect of the Lisp family of programming languages. Lisp was designed by John McCarthy in 1960 (which makes it one of the older programming languages still in use, second only to Fortran). The name stands for List Processing, because one of the key ideas is to use a simple data structure called a list for both code and data. The Roots of Lisp by P. Graham (2001) revisits McCarthy's original article illustrating the code/data evaluation procedure.

Here we skipped several basic definitions and only aimed to give a flavor about the Scheme notation used in SICM. For more details, refer to:

• SICM, appendix Scheme: an introduction to the Scheme programming language.
• SICM, appendix Our notation: details about the functional mathematical notation adopted by the book and how generic arithmetic extends basic operations, such as addition and multiplication, to a variety of mathematical types. The discussion about differentiation and of tuple (a generalization of tensors) arithmetic is also interesting.

Note. This section is rather technical and aimed to illustrate a subtlety used above that shows the flexibility of the Lisp syntax (despite its simplicity).

The procedure L-free-particle was defined as a function of mass and of the local tuple as:

(define ((L-free-particle mass) local)
  (let ((v (velocity local)))
    (* 1/2 mass (dot-product v v))))

It may seem simpler to define it as (define (L-free-particle mass local) ...). However, we want to compose (L-free-particle mass) with other functions by itself.

Let's consider a minimal example. The following definitions are equivalent and bound the procedure (lambda (x y) (+ x y)) (where lambda denotes an anonymous function) to the symbol foo:

(define foo (lambda (x y) (+ x y)))

(define (foo x y) (+ x y)) ; Same as before, using syntactic sugar.

Let's consider also the following equivalent definitions:

(define bar (lambda (x) (lambda (y) (+ x y))))

(define (bar x) (lambda (y) (+ x y)))   ; Syntactic sugar.

(define ((bar x) y) (+ x y))            ; More syntactic sugar.

For the simple purpose of evaluating \(x+y\) (e.g., for \(x=2\) and \(y=3\)), both cases work:

(foo 2 3)
;Value: 5

((bar 2) 3)
;Value: 5

However, the second case allows to compose bar with other functions of one argument. For instance, let's compute \(x^3+y\) (for \(x=2\) and \(y=3\)) as:

(((compose bar cube) 2) 3)
;Value: 11

A similar composition of foo with cube is not possible because foo requires two arguments, while cube one.

It is remarkable how a simple idea such as using lists for both code and data naturally leads to (a priori non-trivial) procedure composition.

The examples shown above are based on the powerful scmutils library for the Scheme programming language. The library is libre software, developed for education and research at MIT.

Once installed, all the procedures illustrated above can be easily evaluated through the interactive Scheme REPL (read-eval-print loop), similar to (but way more powerful than) an interactive shell.