Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Learn Physics by Programming in Haskell [pdf]

arxiv.org

Post reply on HN
Print view View original

51–56 of 56 posts

Re: Learn Physics by Programming in Haskell [pdf]

#51

Post by agumonkey »

noobermin wrote: post #32

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 n…

A great deal of Mathematics were done in tables, vectors and matrix, that mapped (probably because of a feedback loop) so well the imperative indexed loop that it's not surprising they'll love it.

On the other hand, watching Gilbert Strang videos, I had the feeling that his views on maths were very FP-ish. Splitting matrices into sub-matrices, combining them with higher order operations. No i,j,k index ever to be seen.

Re: Learn Physics by Programming in Haskell [pdf]

#52

Post by lrc »

noobermin wrote: post #32

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 n…

I love FP, but in order to learn to love it you have to get used to the idea that the language is going to be doing a few things that you might not like (collecting garbage, silently boxing things, not knowing how to convince the system to use the vector operations provided in hardware). With Fortran/C, it's easy to see how assembly language gets produced. I like Haskell a lot, but while I know how C(++) gets to the iron I'm pretty vague on how Haskell does it. FP can still win, or approach parity, but it costs some trust

Re: Learn Physics by Programming in Haskell [pdf]

#53

Post by lrc »

stolio wrote: post #48
lrc wrote: post #46

Earlier quoted context omitted.

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…

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.

Re: Learn Physics by Programming in Haskell [pdf]

#54

Post by soegaard »

stolio wrote: post #36
notthemessiah wrote: post #29

Earlier quoted context omitted.

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

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.

Re: Learn Physics by Programming in Haskell [pdf]

#55

Post by Guvante »

wyager wrote: post #31
Guvante wrote: post #13

Earlier quoted context omitted.

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)

>Haskell requires that the two operands and the resultant type share a type. Most physical unit libraries simply describe a "unit-ed" multiplication/division/etc operator, so you write code like let v = (5 ~* meter) / (1 *~ second) This division operator would replace the standard one. This requires using Haskell extensions that support dependent types, but the libraries certainly exist. I've used "Dimensional" befor…

Certainly avoiding using naked `*` avoids the problem, I was talking specifically about that operator.

Re: Learn Physics by Programming in Haskell [pdf]

#56

Post by Guvante »

JadeNB wrote: post #47
Guvante wrote: post #13

Earlier quoted context omitted.

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)

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

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