Hacker News Reader

Comment by stolio | Hacker News Reader

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...

book: http://mitpress.mit.edu/sites/default/files/titles/content/s...

View on HN

Additionally by Sussman is Functional Differential Geometry. This builds on work from SICM and delves into ideas of Relativity.

Interestingly, the second edition of the book will be published next Friday.

Do you know if it has changed enough to deviate from the course or not? I just found out about this and it sounds really interesting, and I'd like to get the newer book if I can.

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

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...

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

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

I wouldn't say "the Racket people" gave up - rather that one Racket user gave up. If I were to port scmutils to Racket, I'd probably start from the Guile port.

I'm working on a port to Clojure: https://github.com/littleredcomputer/math .

(The name is a little vague, I haven't decided what to call it; "scmutils" doesn't convey much).

Having it in Clojure means it could be integrated with lots of other things; I'm considering graphics, at some point, or some kind of integration with javascript.

I'm a daily reader of HN, but not much of a contributor (sadly): do you think this might be worth a Show HN when it was more mature?

I've been putting off the SICM course and thus scmutils but the idea of a Clojure port makes me a little giddy. 2 good things I see: the possibility of using it in bigger projects (sorry, Scheme) or just not dealing with context switching from Emacs/Clojure to Edwin/Scheme.

Either way - really cool, wish I could help but I don't really know how.

Thanks! I grew up with Scheme, but set lisp aside for years until Clojure came along to reboot my interest.

That book absolutely blew me away the first time I worked through it. Great stuff!

I've yet to finish my way through. But it is amazingly precise and thorough. There are a few mistakes that the reader catches easily if they've been paying attention.

The authors are really onto something with programming as a means to learn other subjects. I know there is a very recent book on differential geometry topics from them also!

Would you happen to have proof of property d of exercise 1.33 lying around? (The one on the Euler-Lagrange operator of a composition of Lagrangian-like functions)

The authors are really onto something with programming as a means to learn other subjects.

I think this is because of the precision that programming demands. You have to really nail down every edge case, and think about things down to their essence.

This is one reason why programmers can succeed in jumping the fence to work in their customer's jobs, even when it's an unrelated field. (I've seen many programmers make swaps from fields as diverse as brand management, telecom customer support and bond trading)

I think it's actually as much to do with having to turn syntax and abstraction into something actionable that describes the solution.

That is, in programming you learn a small set of abstractions (programming language syntax), and the actual coursework in applying that is in how they combine, how to fit them to problems.

In math, you learn a large number of abstractions (notation), that can vary and have new ones across different domains, and which doesn't tell you what it is doing unless you learn all the abstractions.

The latter you can kinda get, if you think about it, but forcing you to actually turn it into something expressed in the former means it is synthesized into something applicable, rather than just abstraction that may or may not be.

That is,

http://upload.wikimedia.org/math/d/f/1/df17b3410e58ac4c285bc...

is harder to understand when you come across it than

  total = 0;
  for(i = 0; i<=100; i++)
  {
     total += i;
  }
  return total;

  sum([1..100])

You have to convert the first from a symbol that does not describe its action, to an action; the code describes the action. That extra translation step leads to additional cognitive load when learning, at least for me.

Alternatively, you could just note that your example reduces to 100*(100+1)/2. This simplification decreases cognitive load even more substantially! Taking a strictly programmatic view of a problem allows you to be lazy, and I believe that you lose a lot in the process. There is importance (numerically, even!) in thinking about things in a more formalized, mathematical way.

But your second code snippet is almost a verbatim transliteration of the image URL, so in what sense is it easier to understand?

(verbatim transliteration would be

    sum (map (\i -> i)) [1..100]

)

Reply on news.ycombinator.com