
Learn Physics by Programming in Haskell [pdf] - lelf
http://arxiv.org/pdf/1412.4880v1.pdf
======
stolio
If you're into physics I'd recommend solving some problems using whatever
language, but especially functional languages (i.e. Lisps, Haskell, etc.)
because you have some big "A-ha!" moments as to what the math really means.
Like when you program an integral from scratch for a mechanics problem and you
go "Oh _that 's_ why we use an integral here!" There are also many problems
(i.e. n-body orbital dynamics) where brute-force computation is the only way
to get to a solution. Finding the path Rosetta/Philae took to comet 67P comes
to mind.

There's an older course that's a bit of a sequel to Structure and
Interpretation of Computer Programs (SICP) called Structure and Interpretation
of Classical Mechanics (SICM). I've never done it but always thought it looked
like fun. (If you're into Scheme or Lisp)

course: [http://ocw.mit.edu/courses/earth-atmospheric-and-
planetary-s...](http://ocw.mit.edu/courses/earth-atmospheric-and-planetary-
sciences/12-620j-classical-mechanics-a-computational-approach-
fall-2008/index.htm)

book:
[http://mitpress.mit.edu/sites/default/files/titles/content/s...](http://mitpress.mit.edu/sites/default/files/titles/content/sicm/book.html)

~~~
notthemessiah
One thing that somewhat turned me away about SICM is that it relies almost
entirely on a specific Scheme implementation and Emacs setup.

~~~
stolio
Edwin (the text editor that comes with MIT-Scheme) is not quite emacs, but
when I used it for SICP I kind of liked it...once I figured out the debugger.
_(edit: that sounded sarcastic, I actually liked Edwin)_

Apparently there's an important library for the course called scmutils that
the Racket people gave up on porting a while back: [http://lists.racket-
lang.org/users/archive/2005-October/0099...](http://lists.racket-
lang.org/users/archive/2005-October/009964.html)

~~~
rev
There is also a port to Guile: [http://www.cs.rochester.edu/~gildea/guile-
scmutils/](http://www.cs.rochester.edu/~gildea/guile-scmutils/)

~~~
j_m_b
Oh sweet a guile port.. thanks for posting that!

------
evanb
Please don't link straight to PDFs on the arXiv.

Link instead to the abstract:

[http://arxiv.org/abs/1412.4880](http://arxiv.org/abs/1412.4880)

------
flannelhead
I'm a physics sophomore, and I would be very glad to see more programming,
especially FP, integrated to physics courses. During my studies, I've
programmed some simulations related to the physics courses I've taken. My main
purpose has been to gain a deeper, more practical insight on the subject which
would've otherwise remained quite theoretical and distant.

For example, I made a little rollercoaster simulation to demonstrate the power
of Lagrangian mechanics and generalized coordinates to myself. On the
electrodynamics course I programmed a solver for Poisson's equation using the
finite difference method to see a little more than the few simple geometries
we calculated by hand. That kind of voluntary activities have greatly
motivated me and helped me to understand various concepts.

On some courses we already have some simulation work and numerics in homework
problems. Maybe deeper integration of programming into teaching requires time
and, more importantly, a driving force and resources behind it. Then, of
course, not everyone would be happy to see that kind of integration – I'm sure
some would feel like they're forced to learn to program. And, as it has been
seen on our entry level numerical physics course, learning programming,
numerics and physics the same time is really quite hard.

Given those shortcomings, I still feel this is the way to go for future
physics education. A gentle introduction and slowly teaching programming
alongside physics would be the key, I think.

~~~
Steuard
Have a look at the _Matter & Interactions_ textbook by Chabay and Sherwood.
It's a really cool concept for a first-year physics course, and it
incorporates a lot of programming (and even just programming-inspired
perspectives). (The authors use the "VPython" programming package for easy
creation of 3D simulations.)

~~~
jeffreyrogers
I'll second this. I took a course using this textbook and it was one of my
favorites.

------
jonjacky
This 1994 paper (using Scheme) might be pertinent:

Fields in Physics are like Curried Functions or Physics for Functional
Programmers:
[http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.49.1...](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.49.1181)

~~~
agumonkey
Actually I wonder how much Curry took from mathematics tendency to parametrize
abstractions, leaving variables for later, in his work.

------
bkcooper
I am intrigued by this approach (I have _Structure and Interpretation of
Classical Mechanics_ on my lengthy to-read pile) but I do wonder whether
expecting ~sophomores to be trying to pick up Haskell and the physics at the
same time is a bit much.

The aspect of this that interests me most is related to a classic observation
that, for most people learning physics, it's hard to separate difficulties
with the physical content and difficulties with the mathematical content. The
distinction between these is vague, but the separations like "set up the
differential equation" vs. "solve the differential equation" that this
functional style suggests seem like a good approximation to "physics" vs.
"math."

~~~
jarcane
If you're only dealing with pure maths, Haskell really isn't that hard to pick
up, it's only once you start wanting to do I/O and deal with monads that it
can be a bit of a burden.

For something like this, where you're probably just loading some pure
functions into GHCi? No harder than Mathematica or something like it really.

------
jaked89
"One obvious use of types in physics that we have not explored in this work is
the expression of physical dimensions (length, mass, time) and units (meter,
kilogram, second).

...This is not trivial to do with Haskell’s type system because one wants
multiplication to “multiply the units” as well as the numbers."

F# supports units: [https://msdn.microsoft.com/en-
us/library/dd233243.aspx](https://msdn.microsoft.com/en-
us/library/dd233243.aspx)

~~~
Guvante
And note that there is no way to resolve this without some fundamental changes
as Haskell requires that the two operands and the resultant type share a type.
(Otherwise you could do some tricks with recursive types to accomplish this)

~~~
JadeNB
I think that this is true only if you want to be an instance of `Num`, which
makes sense: the collection of, say, lengths is _not_ such an instance,
because you cannot multiply two lengths and get a length. Nothing stops us
from defining (simplified)

    
    
        data Unit a = Unit a [String]
    
        (*) (Unit a as) (Unit b bs) = Unit (a Main.* b) (as ++ bs)
    

Of course, we will then have to disambiguate ` _` when we use it in the code.
Another option would be to give it another name, like `_ unit` (or something
less awful).

~~~
Guvante
I didn't think there was a way to set `*` without losing `Num` (which is
required for raw numbers in your code).

------
cubano
Man, do I feel old.

Back in undergraduate school, we were taught to learn programming (FORTRAN)
through physics, not the other way around.

The idea that the process could be turned around really hammers home how much
things have changed due to the access to computers at a young age that most
kids have nowadays.

~~~
drostie
I learned programming independently, but I've done a Master's in physics.

I really think that you want the curriculum to go in this order: (1) teach a
high-schooler to program via games; (2) leverage that programming knowledge to
build up some abstract mathematics and love of patterns; (3) start into
Newton's equations with a programming background.

Haskell is actually a pretty good choice for this process because it is
functional. I wouldn't tell the student that it's a "functional language" but
rather that it is "based on a simpler model of computation". You start with
the idea of "expressions reduce", the naming of things, and backslash-function
literals. Once you understand that, then there are data structures and pattern
matching -- you expand slowly outwards this way.

The syntax is surprisingly simple if you explain it top-down, but is often
"lighter" than Lisp's parentheses. Curried functions and operator sections let
you easily speak about high-level functions really early on without a mess of
syntax. Haskell guards and pattern matching really embodies the SICP value
that "every good program starts with a case dispatch." And, you can still do
SICP's trick of implementing a Scheme dialect in Haskell pretty easily (in the
context of games this allows them to be "scriptable").

The value that you get is that in the mathematics courses, you are sneakily
starting a student off in a proof-centric environment; you can start calculus
with the discrete calculus

    
    
        delta list@(x : xs) = x : zipWith (-) xs list
        sigma = scanl1 (+)
    

...and you swiftly get an inductive proof that sigma and delta are inverse
functions.

Because computers are stupid, you really break every idea down to the lowest
common denominator, which makes it really easy to incrementally learn.

~~~
machinshin_
that sounds so fun. I would love to take a class (or classes) like that :)

------
noobermin
The thing is from my experience, most computational individuals would be
strongly opposed to FP. They may not have been raised on for loops, but once
they learn about for, good luck on having them warm up to the idea of map and
reduce.

I think the only way you'd succeed is by snatching their young before they go
down that path. I don't really see many people warming up to new things aimed
at them like Julia or even not-so-new stuff like numpy/matplotlib and friends.
If it isn't Fortran or C or matlab, it doesn't ring well with them. Of course,
the new kids who don't know programming (or physics yet, perhaps) are ripe for
indoctrination of your religion as opposed to theirs.

~~~
ky3
_most computational individuals would be strongly opposed to FP_

There's ample evidence for and against. The most famous counterpoint I know of
is Dijkstra, whose Ph.D. was in theoretical physics. What does a theoretical
physicist do? They calculate, of course. On reams and reams of paper.

Dijkstra famously warned against the brain damage that comes with learning
BASIC. I understand it to mean that one could be so caught up with the details
of shuffling bits and bytes that a bigger picture is no longer conceivable to
the poor fellow.

Because the poor fellow has fallen into the trap of premature optimization.
For loop all the things, higher abstractions be damned.

~~~
mcguire
A couple of random bits of trivia:

* Dijkstra's Ph.D. was in theoretical physics, but I don't believe he ever actually did much. Instead, he was working on computing systems. Famously, when he was getting married, the Amsterdam official recording the marriage wouldn't accept "programmer" as a job, so his marriage certificate says "theoretical physicist."

* Dijkstra was not a wildly big fan of functional programming. Admittedly, he was less a fan of other things, and I've had this sneaking suspicion that his was simply another allergic reaction to recursion, but still...his guarded command notation was essentially imperative.

------
mattegan
At Georgia Tech, the labs associated with Physics I and II have a large
programming portion. They had us use VPython [1], which is a strange package
which includes a version of python and a graphics library. It worked pretty
well, and I got a good kick out of it. They had us model gravitation of
planets (using discrete time steps). In Physics II one of the assignments was
to create vector field displaying a magnetic field, and then animate a magnet
around the field in a circle.

I think the programming might have been a little too complex for some, as some
people took physics first or second semester before having a programming
class, and it became difficult for the TA's to help people with their code as
they taught how to accomplish things, not accomplish it in a clean manner.

Overall though, I think it added a good bit of value to the course.

[1] : [http://vpython.org/](http://vpython.org/)

~~~
poikniok
Note that this is only for modern physics 1 and 2, which I think roughly half
of the students take, the rest taking the classical physics 1 and 2.

~~~
mattegan
Yes. Though they are pretty "hush hush" about the differences between the two
classes, in fact, the course numbers are the same, it's just common knowledge
that one professor teaches "Modern" physics, and one teaches "Classical"
though, those are kind of informal, the differences are not in the material,
but mainly in the teaching style.

------
JadeNB
Continuing my mission to promote links to abstracts over links to PDFs:
[http://arxiv.org/abs/1412.4880](http://arxiv.org/abs/1412.4880) .

------
al2o3cr
The linked paper doesn't address the elephant in the room - numerical
integration is a finicky process to work with in many systems. Students who
are still working to understand the underlying concepts are not going to be
helped by things like non-energy conserving integrals. [1]

The lack of units in the type system also means the error-preventing
properties of static typing are somewhat limited here; it's possible to write
code that assumes F=a/m without any complaint from the compiler.

[1]
[http://en.wikipedia.org/wiki/Energy_drift](http://en.wikipedia.org/wiki/Energy_drift)

~~~
gosub
[https://wiki.haskell.org/Physical_units](https://wiki.haskell.org/Physical_units)

------
swatow
I think the problem with this sort of thing is it doesn't capture the beauty
and elegance of either Haskell or physics. Take the first line

    
    
      data Vec = Vec { xComp :: Double
        , yComp :: Double
        , zComp :: Double }
    

The author has just defined a 3d vector. But there is no "3" in the above
because Vec is hardcoded to be three dimensional. The physics student is
probably interested in what aspects of physics are special to 3 dimensions,
and which generalize to higher dimensions. I think geometric/Clifford algebra
somewhat answers this, but my knowledge is limited. Anyway, functional
programming is still at the stage when the things that it can express about
mathematics, are actually pretty obvious already. I have high hopes for the
future (e.g HoTT), but for now functional programming is much more exciting
for programmers than physicists or mathematicians (who aren't logicians or
category theorists).

------
howeman
Just don't run your pendulum simulation for too long if you're using the Euler
method!

------
eli_gottlieb
Neat. I'll have to try that out some day.

