Having come to mentally “compute” everything in Lisp/Clojure-style, is prefix (Polish) notation good for math? I’m playing around with doing algebra and calculus even on paper, using prefix notation. Has anyone here tried this?
I realize there are wikipedia pages on Polish Notation and the Polish Mathematics movement from which it comes, and I also realize that prefix notation makes computational sense (hence S-Expressions); does it have any advantages or drawbacks for humans, though? Besides the fact that every math text you are likely to encounter uses infix instead?
If every function has a fixed arity (unlike Clojure’s basic arithmetic functions, e.g. *), it’s possible to write Polish notation without parentheses. However, this is inherently difficult for most humans to read, I believe, because we are not good at managing complex stacks in short term memory.
The unix-pipe style operators in Clojure are popular because it’s easy to simply read through a sequence in order. I don’t prefer them very often, but everyone’s different.
For complex mathematical expressions, though, I do prefer being able to read from left to right, being reminded that this next expression is to be added because there is a + sign right in front of it. i.e I prefer infix syntax, and I don’t think that is only a matter of habit–but that’s just my intuition. For me this is a drawback of lisps, but nothing’s perfect. (I don’t like using an infix macro system; it makes code confusing in a Clojure context.)
(This is one reason that I started using OCaml as well as Clojure. OCaml math syntax has other drawbacks, though, and it’s very different because it’s statically typed.)
Thanks for the reply, @mars0i. I’ve been curious whether certain pen-and-paper operations operate differently in PN, and how gracefully I can work out problems. Note that I’m not trying to use Clojure to compute – just as the notation for hand-working problems. Here’s the homework that inspired the question:
In my opinion it’s just a matter of familiarity but that one is ingrained at a very small age, so I find it is much harder to adapt to polish notation for arithmetic use as opposed to programming.
I don’t have a big background in math, so I prefer prefix. I can definitely read it better than infix (plus all the other precedence rules and notation).
It’s pretty clear that some problems are easier to work out with a choice of notation that’s tailored to that problem. For example, some matrix problems are much easier if the structure of the matrix is rearranged without changing its mathematical essence. So I wouldn’t be shocked if you found that some problems are easier with prefix notation, Webdev_Tory.
Personal opinion: Clojure’s advantages are that (1) you don’t need operator overloading and (2) you don’t need to remember the infix operator associativity table. No extra fuzz, just use functions with good names.
(1) Operator overloading. In math, you might want to define plus on your own datatype. In Java, you basically can’t touch the plus. In Python, you might have a better chance, but you’d still have to “extend standard plus semantics”. In Clojure, you can just provide your own math namespace, and do (my.math/+ a b). Optionally, you could just import your own plus and avoid the default provided one.
(2) Some languages allow you to create your own operators. Haskell is one of them. But in Haskell, you have to keep the infix table in mind. Each infix operator has its precedence (higher precedence is “collected together first”) and fixity (whether a + b + c = (a + b) + c (infixl) or a + b + c = a + (b + c) (infixr)).
This can become really confusing. You get a bunch of operators where you need to know fixity and precedence. Then you create a super-smart, super-long epressions with a bunch of arrows.
Following is an example of how you can use it. First, we define two “plus-like” operators $+$ (left-associative) and $++$ (right-associative). Pay attention to how they combine in the REPL session.
Note: ClojureVerse syntax hightlighting didn’t seem to like Haskell, so I created a gist (same as source below).
-- source file
module Lib where
someFunc :: IO ()
someFunc = putStrLn "someFunc"
data Expr a =
Number a
| Plus (Expr a) (Expr a)
deriving (Show, Read)
-- shorthand for number, type constructor for Expr
n = Number
($++++$) :: Num a => a -> a -> a
a $++++$ b = a*a + b*b
($+$) :: Expr a -> Expr a -> Expr a
a $+$ b = Plus a b
infixl 6 $+$
($++$) :: Expr a -> Expr a -> Expr a
a $++$ b = Plus a b
infixr 6 $++$
-- Run this in a `ghci` or `stack ghci` -- this isn't really a file.
*Main> :load Lib
*Lib> n 10 $+$ n 20 $+$ n 30
Plus (Plus (Number 10) (Number 20)) (Number 30)
*Lib> n 10 $++$ n 20 $++$ n 30
Plus (Number 10) (Plus (Number 20) (Number 30))
Nice job! I think implicit operator precedence is a misfeature, and I actually prefer prefix notation for larger expressions. Sussman talks about this a bit in the context of using scheme to teach classical mechanics (see SICM). More in this video:
@jackrusher, I’m curious as to what part of the video you found related to this thread. Was it the part where he extended the number system to include units and such? Thanks for the link, I enjoyed it. (and it was interesting to listen to your appearance on The Future of Coding podcast!)
During his discussion of the drawbacks of classical mathematical notation he talks about using scheme to encode classical mechanics with a particular emphasis on the Lagrangian. He mentions as an aside that dealing with large equational systems in that language is quite easy, emacs takes care of the structure-editing issues, and so on. I have found the same thing to be true.
i really love SICP,… also i was trained as a mechanical engineer at TUM,… so i did spend a lot of time pondering classical mechanics… and therefore i would really like to take a closer look at SICM… but when i stumbled across this a while back and had a look… i have found it to be a really tough read… now, years later, i took another look… and it feels to me like the math has gotten even more challenging :-)…
also… for someone new to classical mechanics ( and interested ), this is how i got started :-)…
We used the Meriam and Kraige textbook when I took Statics back in the 80s. Like the Dietmar Gross text, it was mainly concerned with mechanical/structural engineering, whereas SICM was largely motivated by the use of differential geometry in the context of celestial mechanics.
i think i may have had a look at Meriam and Kraige at one time in the library… back in the day… wow… this mechanics stuff really takes me back ( in a good way!!! ) … also we had a lot of classical mechanics, so the first semester was just statics, then elasticity came in, then kinematics, then fluid-mechanics and numerical methods… ( wall… one of the authors … was actually my prof back then… but he is really a numerical methods person… so celestial mechanics sounds right… but we really did much more down to earth kind of things ) … also the various books were really the textbooks for the various courses / semesters,…
in any case, i just think that going into the SICM text cold turkey is kind of brutal,… although it may be true that working your way through statics etc. first may be a bit much… since… hmm… i guess in high school we did learn about newtons laws of motion without ever talking about stress and materials or anything like that… so… hmmm… now as i write this down… i am starting to think that you make a really valid point
…still… i imagine the SICM text to be a near-impossible undertaking for anyone who comes from a pure computer science background and did not take any serious lectures on higher math / physics,… since i think that the discrete math that computer science is focused on, that math is quite different from your century old math / physics… of the kind you find in SICM ( … at least from what i was able to see… )… because,… ( i am not quite sure how to put this,… )… i just feel like combinatorics and differential equations live in two very different areas inside the brain… but… perhaps… it is just that i have not yet been able to see the larger picture…
Wie alles ſich zum Ganzen webt,
Eins in dem andern wirkt und lebt!
… this is from faust and it means… hmm… well… hmm… things are really more connected than one may think…
… also we had a lot of classical mechanics, so the first semester was just statics, then elasticity came in, then kinematics, then fluid-mechanics and numerical methods… ( wall… one of the authors … was actually my prof back then… but he is really a numerical methods person… so celestial mechanics sounds right… but we really did much more down to earth kind of things