I have just enjoyed reading a very nice tutorial paper on Functional Differential Geometry, by Sussman and Wisdom. It is written in the same spirit as an earlier paper with the provocative title, The Role of Programming in the Formulation of Ideas.

One of their basic claims, actually elaborated in great detail in the latter paper, is that many scientific ideas are somewhat fuzzy in the way they are usually taught and communicated. For instance, when one derives equations of motion in the standard Euler-Lagrange method, one is glossing over many potentially dangerous issues – including (in)dependence of variables with respect to which one is differentiating, the region of applicability of the relationships, etc. The proposed solution is to explicitly implement everything in a program, preferably a functional program, so that the fuzziness is exorcised. All this is great, of course, but since I read the ‘Formulation of Ideas’ paper many years after first encountering the E-L equation, I was not sufficiently confused to truly appreciate the power of this argument.

Today, when I revisited the differential geometry paper, I *was* trying to come to terms with the meaning of many of the concepts – such as what exactly does a connection *mean *from the point of view of learning the dynamics of a system. So, on this pass, I greatly appreciated their approach. In fact, I suspect that the real power is not even in the programming of the concepts but in the operationalizing of the abstract concept in terms of something concrete – so that I may first start from the scaffold on which to build the grander structure.

The next time I need to understand an abstract concept, I will be that much more inclined to somehow code it up…

### Like this:

Like Loading...

*Related*

My counter argument is that the details obscure the intuition. The formalism of Differential Geometry hides the very simple concepts in it: coordinate changes, metric definition of surfaces and mappings (isometries, etc). I looked at the paper and was spooked by the complicated codes… I would rather like a language that grasped the concepts, and hid the details. That would be the holy grail of automated computing.

Yes, that is an important point.

I was coming at this from the point of view of an algorithm designer – in which case, I suppose, the coding analogy is just natural and not very surprising.

On further reflection, I think the reason I liked their point is that I want to understand these things constructively. So, it is great when someone proves that something exists (or not) by very indirect methods but I need to get my hands on that thing in order to appreciate it – and use it in an algorithm to do something with it. So, for instance, if I am looking at the mathematics for a representation that expresses everything about the dynamics of my problem then I want to see that it really does what I expect.

But, clearly as you point out, the two approaches must complement each other.

Agreed. Especially if one wants to build tools that can automate “intuition” extraction, then both have to interact.