I could not disagree more with that post. Mathematical notation is to Python what English would be to Assembly Language: it is a high-level notation, designed see the forest rather than getting lost in the trees.
Take Maxwell's equations for example. After learning vector calculus and becoming familiar with its notation, you notice how much meaning you can extract at a quick glance from the four Maxwell's equations expressed in differential form. The purpose is not to obfuscate the meaning (like the author implies when he mentions the Obfuscated C contest) but rather to reveal/encapsulate as much information as possible in a way that is easy to understand at a glance. You want to know what would happen if magnetic monopoles existed? Easy to do by just adding a few extra terms that are obvious by symmetry of the equations.
And, if you go beyond vector calculus, you can see an even clearer picture by writing
F = dA (equivalent to the usual two homogeneous Maxwell Equations)
d*F = *J (equivalent to the remaining two)
> Mathematical notation is to Python what English would be to Assembly Language
Which is often the problem, it looks specific, but it really isn't; it's full of implicit assumptions about what the reader should know. It's not executable, because it's a language designed for being written by hand rather than executed by a computer.
However, the teaching of math would greatly benefit from an explicit executable form that makes no assumptions, i.e. a programming language. Gerry Sussman makes this case, he's pretty convincing.
I couldn't possibly disagree more with your post. :)
The language of math requires exact precision which makes extracting what the series of abstract symbols "mean" incredibly difficult. Trying to learn new mathematical concepts from wikipedia is damn near impossible. Here are two examples.
Trying to figure out what those walls of symbols mean requires quite a lot of focus. Dig up source code for either and it's orders of magnitude easier to understand. The images for spherical harmonics conveys more meaning and understanding in a fraction of a second than spending 3 hours with a piece of paper and the equations would.
1. I came into this thread expecting to find a math expert of some sort defending their "programming language". Thank you for not letting me down!
2. It depends on context. The people writing and manipulating mathematical formulae LOVE the short hand I'm sure... but for consumers of the information perhaps it's less than ideal.
No, that's not why math is painful to read. The reason math is painful to read is because it's either obvious, in which case it's not painful to read, or because it contains new ideas that you need to work hard on before you can grok them.
There is no short cut. You can't write math like a novel, you can't read math like a novel. There are ideas that are deep and difficult, and unless you actually spend time working on the material you simply won't "get it."
Time and again I have explained to people something that's comparatively simple, and easily within their grasp. I've tried different approaches, different formulations, different arcs through the material, and time and time again the person has followed every step in detail, and just not "got it." There is no enlightenment, there is no sense of what's happening. It's only after they've invested the time that they have come to a sense of what's happening, and then the light dawns. Occasionally they say things like "Why didn't you explain it like that in the first place?" Then I point out that I did, but at that stage, they weren't ready for it.
It's like following a SatNav. You get to your destination having followed the turn-by-turn instructions, and yet, in truth, you really have no idea where you are. You have traveled from one local pocket to another local pocket, with no understanding of the space through which you've been.
Math is painful to read because you're trying to follow the turn-by-turn directions, instead of taking control of your own understanding and working to gain knowledge and insight, scope and intuition.
You won't understanding it without doing the work, and complaining that it's badly written is the smallest part of the problem.
> The reason math is painful to read is because it's either obvious, in which case it's not painful to read, or because it contains new ideas that you need to work hard on before you can grok them.
The same could be said for code that uses only single letter variables and functions.
It'd be a lot easier with readable variable names.
val result = directProduct(cyclicGroupOfDegree3, finiteAbelianGroupOfDegree7)
and the second kind, people like me, who do this:
// Compute the direct product of 2 cyclic groups
val z = dP( cg1, cg2 )
You can easily guess that the 2nd kind are math majors. If my math professor started writing everything out in plain English like the first example, he'd never be able to cover a theorem per class. He'd still be writing the first lemma and the hour would be up.
So he resorts to 1-character symbols, precise notations, and terse comments. The idea is - if the reader doesn't grok direct products or cyclic groups, he's fucked anyways, so why bother ? And if he does grok them, why impose cognitive overload by spelling it all out in great detail, just use 1-character symbols and move on.
Now both these styles are in direct conflict with each other, and in the Fortran/C/C++ community during the 80s-90s ( when every respectable programmer had a copy of Numerical Recipes on their desk ), you would emulate the 2nd kind.
In the 2000s & later, people got rid of their Numerical Recipes & exchanged them for "14 days to EJB" and "Learn Python in 21 days" and "Master Ruby in 7 days" and the like...the community started becoming a lot less math-y and a lot more verbose, and style 1 is back in vogue. Nowadays I get pulled up constantly in code review for using single character names....but I think this too will pass :)
cyclicGroupOfDegree3 is a terrible name, unless you need to be really specific about degrees. cyclicGroup, please. (and I could imagine: cyclicGroup.degree() == 3)
dP is also a terrible name. My first thought goes to derivatives. directProduct is the right name. dProduct, dProd (if you like the Numerical Recipes style, expounded below) are better than dP, but still wrong for a library.
So first, let's assume directProduct is a library somewhere; maybe one you've even created. So let's reconstruct:
val z = directProduct(cg1, cg2)
Better, and more believable. And if the declarations of cg1 and cg2 are obvious (ie, the lines directly preceding) then you might have a case. I imagine directProduct(group1, group2) would actually be a happy medium. And if you use z in the next line or two, I'd let that slide.
The thing about Numerical Recipes is that often you're taking math syntax and coding it. Often doing so requires a good deal of commenting and temporary variables. One thing the book gets very wrong is it's function declarations (the function body is a separate argument) -- at the very least, rooted in a past of 80-character-lines and before code reviews. The first example in the book:
void flmoon(int n, int nph, long* jd, float* frac)
ought, in a modern era, be something like:
void MoonPhaseToDay(int n_cycles, int phase, long* julian_day, float* fractional_day);
If for no other reason than I can have some hope at understanding the second argument, or finding it again. You'll also notice flmoon is a misnomer -- it computes more than full moons!
The idea is - if the reader doesn't grok direct products or cyclic groups, he's fucked anyways, so why bother ? And if he does grok them, why impose cognitive overload by spelling it all out in great detail, just use 1-character symbols and move on.
This case analysis works if you only consider people who've been sitting in on the class the whole time, but someone who appears mid-way through the semester (or analogously, starts looking at some project's code without having been involved in its development) may understand group theory and still have trouble following the lecture.
// Compute the direct product of 2 cyclic groups
I would much rather give the function a name that describes its purpose (and give a full description in a comment at the function's definition) than annotate every use of the function.
I would argue that the self-documenting code in your first example (albeit excessively verbose to suite your argument) is better than having to put a comment above every terse statement one writes?.
Programming with descriptive and meaningful variable / function names that have intrinsic meaning skips this step: 'wait, what was the cg2 again? let me waste time by looking back through the code and figuring that out again'. Particularly for others reading your code later.
But I try to fit somewhere in between the two examples you've shown, meaningful but not too long -> the benefits of longer variable / functions names diminishes when names get too long as variable names tend to blend together (see law of diminishing returns).
To me, I highly prefer the first expression you've written (well, without the exaggerated style you've given it). The second may save you some time in the short run, but when you come back to your code in a year, you think you'll know what dP means? Differential of P? Distance to P? Distance from P?
I realize you've got a comment above it, but if you really code like that then you are very different from any code I've come across where the programmers used short, non-descriptive variable names.
As my coding has improved over the years, I've gone from an imperative, abbreviated variable style to a functional, long-named variable style. Even with the long names, my code is MUCH more readable and it's still about 2x less typing than the imperative style!
(Also, I don't think all math majors use that second style).
Math notation should be terse because you have to do symbolic manipulation on the expressions. It's easy to argue for longer variable names when you are just using the ready-made results. I think it's acceptable to use long names for programming.
I guess by degree you mean order? And by finiteAbelianGroupOfDegree7 you mean cyclicGroupOfDegree7. Of course, you should always use theorems to keep your notation consistent. :)
The problem with math isn't symbology or notation per se, it's that it's not evolved to take advantage of modern technology. It's an artifact of pencil-and-paper being the medium of choice for expressing ideas. We can do much better.
When you are looking at an equation, you are looking at the purest distillation of an idea. Underneath that equation sits countless layers of abstraction and reasoning. Why can't I peel back these layers and see them on my computer or iPad? The equation is the iceberg tip peeking out of the water onto the paper, I want to see underneath. Let me feel around and slowly and confidently fill in the places where my understanding is fuzzy. Prevent me from moving back up to the final equation until everything underneath is fleshed out and solid in my mind. And if bits start to fade, let me quickly react to snap them back into focus.
This is what we are doing mentally anyway when we flip back and forth in a math text referencing previous proofs and equations. Math needs it's "hyperlink."
Anything I say here has been said better and more convincingly by Bret Victor:
Though I will argue that at least in his Kill Math writings he's throwing the baby out with the bath water in a certain sense. Let's keep the symbology as a optimal way to encapsulate our knowledge for the amazing mental leverage it gives us, but give us a way to move up and down the ladder of abstraction in order to facilitate understanding.
Math is such a big field that there tends to be much re-use of symbols, and the limited number of Greek letters doesn't help (no one likes multiple-Greek-letter variable names).
To a mathematician reading the technical literature from his own field, there's no issue with math notation. Problems sometimes come up when a specialist in one field tries to read literature from a different specialty -- but that's true in computer programming too.
This may come as a surprise, but math notation is much more uniform than computer-science notation, including all the efforts to create generic program listings. Mathematicians are reluctant to invent new symbols, but it's sometimes necessary.
When I read computer program source code, I often wish the programmer had summarized the meaning of the code using math notation. I guess that puts me in a position precisely opposite that of the author.
To a mathematician reading the technical literature from his own field, there's no issue with math notation.
Let me guess. You haven't learned much differential geometry?
Constants vary by 2 pi depending on which definition you use. Functions might come before or after their arguments. And, of course, you leave everything that is "unambiguous" out of the notation. (Proving that it truly is unambiguous is sometimes nontrivial for the novice.) Guessing what notation a particular author is using has been known to be daunting, even for other differential geometers.
In grad school I remember sitting down with homework sets and spending longer working out what the question said than I did in solving it once understood.
That said, if you tried to actually write everything out explicitly, it would be impossible to read anything. Compact notation is a necessary evil - without it your brain simply can't think certain things. With it, it is hard for anyone else to figure out what you just said.
For me, it's because each symbol, letter or number is given a ton of weight in mathematical equations. You can't skip over and fill in the gaps later - like reading a book, for example - you have to understand each aspect before the whole makes sense.
The real reason math is hard to read is that it's the distillation of a thousand winding ideas and failed attempts that took hundreds of hours of thinking and hundreds of pages of scribbling, all condensed into the most concise possible three pages of unmotivated line-by-line proof with no context or explanation.
In other words, math is a language for formalizing intuition which, when finally written, unfortunately removes all traces of intuition and leaves only the end result of the thinking, not the path that it took to arrive at the critical insight.
That about sums it up. It's made worse by professors who have been trained to teach things in an unmotivated fashion.
I had a graduate probability teacher who said (paraphrased) "one of the beautiful things about math is that you start with a definition, and you prove some very simple things with the definition... so simple that you feel you're just using circular reasoning. Then you find that your definition is equivalent to a useful property!"
Actually, what happened when the stuff was developed is that someone wanted the useful property, and managed to rationalize a definition which fit. (example: group theory was done for hundreds of years before we had a definition of group. Noether noticed that a lot of folks were writing the same sorts of things in different contexts, so she distilled it down to three axioms.)
For a really concrete example, consider ordered pairs. A person being coy about their intent would say that "we define an ordered pair (x,y) on a set S as a set of the form {{x},{x,y}}, where x and y are in S."
It's safe to say that no one thinks of an ordered pair in that fashion. The intent was to have two ordered pairs be equal if and only if each of the two coordinates are equal. You can prove this from the above definition, but it's far more helpful to tell the audience in advance that we really want a structure with this property.
Which is a beautiful thing, no doubt. The creative process is amazing, but reading through years worth of scribbles isn't the point of the proof. Write a proof, then accompany it with a blog of sketchbook scans and a detailed walkthrough of getting there.
Math researcher here. I agree with the basic idea of this article, but not the specifics.
So: notation is a wonderful thing. If someone can improve on it, then great, but modern math notation is what makes math doable. It's true that there is poor notation and poorly used notation; these things need to be fixed.
Regardless, I agree that math is hard to read. I read a lot of math. It's hard. Part of this is because it involves abstract, complicated stuff that often must be understood exactly. But part is because we are not very good at writing it. Or perhaps we don't put as much effort into making it readable as we should.
Being someone who knows a fair amount about programming (or so I like to think) and also writes math research papers, I've found that some of the concepts used to manage complexity in software are also applicable to math.
In particular, I must agree about scope. I've made an effort in my recent writing to be careful about this issue. Another helpful idea involves how to write good comments in code. Too many mathematical proofs perform some operation without telling the reader why or giving any kind of overview. There is nothing wrong with saying, "Here's what we're going to do," and then doing it, and then saying, "Here's what we just did."
Really good point. That always annoys me with most formulas. I have to dig back several paragraphs (with no scope/indexing tool) to figure out what the individual variables mean.
And a lot of papers do not even bother to explain some variable but just assume the reader already knows it.
One of the earlier commenters made this mistake very prominently enthusing over Maxwell's equations.
Yes of course the formula looks better shorter when you already know what it means. But that completely misses the point that it was written down to explain it to someone who doesn't already know what it means. If you already do you're the wrong target audience.
Longer variable names would help. Or for online paper just have a tooltip that opens the paragraph that explains what the variable mans when you hover over it would also help a lot.
Or maybe some color coding to easily find it (there was a recent link here recent explaining FFT which used this trick very successfully)
But I guess most Mathematicians don't bother because they only write for a small circle of colleagues anyways.
Maxwell's equations were not "written down to explain it to someone who doesn't already know what it means". They, quite simply were written down to express relationships between the motion of charge, and the behavior of electric and magnetic fields as a consequence.
You have to understand the physics behind the equations (what's charge? what's an electric field) as well as the mathematical structure (what's a vector space? what's a line integral?) in order to make use of them. They are equations used to answer questions like "What happens to the strength of this magnetic field if I increase the velocity of this charged particle responsible for generating it"? They aren't meant to be explanatory (but have the beautiful side-effect of explaining how light propagates in a vacuum.)
I agree with you. A book that aims to TEACH should provide the most common form of the equation and provide detailed annotations of what everything is. (Wikipedia should be like this as well since I know no one is using it as a reference).
For a REFERENCE, you can just list the equations in their most commonly used form.
It seems to me like the author approaches math looking for a concise & elegant programming language, but instead just finds...math.
The notion of scope as an integral part of mathematics is a particularly interesting suggestion. Mathematics is the study of abstract, quantitative truths (and falsehoods), and these truths, being universal, have universal scope (although you can constrain some truths as special cases of more general truths, but I doubt this is what the author had in mind). To consider this a problem indicates that the author is searching for a tool rather than a way of thinking.
"Math is such a cognitive overload of operators" because it succinctly describes a great deal of action. A program in a conventional language like C might take a hundred lines to describe what could be described in a handful, using some mathematical notation. If you want a programming example, just look at the average length of an APL program vs the average length of a Javascript or C program.
Math is inherently hard. So is programming. Not many people can do either very well. Even fewer can do both very well. The notations of math are meant to be flexible because math is a tool for discovering new ideas and analyzing their properties. Programs are meant to accomplish some real world task. Criticizing the language of one solely from the perspective of the other is not a useful activity.
The notion of scope as an integral part of mathematics is a particularly interesting suggestion. Mathematics is the study of abstract, quantitative truths (and falsehoods), and these truths, being universal, have universal scope (although you can constrain some truths as special cases of more general truths, but I doubt this is what the author had in mind). To consider this a problem indicates that the author is searching for a tool rather than a way of thinking.
The scope issue is not just for theorems. In programming, scope is about what meanings get bound to what symbols, whether those symbols are types, operators, data, etc. Even in math, we can see a notion of "binding" vs. "bound" vs. "free" occurrences of a symbol: seeing something like "∀x∈N.x+k≥0" would make me think "Ok, I see what `x' is, but what's this `k'?" Treating every definition like it's at top-level makes for unreadable code and unreadable math. Ever had to search back through a document looking for the definition of some notation only to find it buried in an earlier proof of an unrelated theorem without so much as a "Definition: …" marker? I would much prefer not to have to do that again.
Transferred to another domain, "Why should we need scope? What good would that do?" becomes "Why should pronouns have antecedents? What good would that do?" It is important to acknowledge that mathematical notation is also a tool for explaining the ideas one has discovered with it.
Completely agree with you, but from your experience, how many fewer do both very well? I have always been interested in both and I can't imagine having one tool without the other, as they both enhance the way that I think about things. Programming makes the concepts of variables and sigma notation even easier to understand, while math makes it far easier to solve problems. Do people actually get by in programming without math?
> But are mathematicians too embroiled in some misguided quest for Huffman coding?
I think that yes, they are: for centuries, mathematics has been written by hand. It's much easier to write 'f' than 'force'. on a blackboard. Moreover, when writing on paper, with ink that you have to make or buy, with a pen that wears out as you write with it, it makes sense that early mathematicians would embrace a compressed notation. Scribes even did it, so it shouldn't surprise us that mathematicians would.
The compression is based on domain knowledge, and this is only problematic for people who are not intimately familiar with the domain at hand. Physics is similar. Decoding the rocket equation is only possible when you know what m1 and m0 are, or ve, and many properties, constants, and even operations are symbolized with a single greek letter. (Gradients, for example)
This is very powerful, because (as others have mentioned) it allows you to easily write more-complex things, and often times you (as a mathematician or physicist) prefer to think at a higher level of abstraction. It also makes it tremendously arcane for those of us who don't even know the names of the greek letters, let alone have a sound backing in that particular field of math or physics.
The compressed notation is not just about saving paper and ink.
It's all about the amount of mental power and work you have to exert. If I'm filling a few pages with equations, if I have to write 'force' instead of 'f' all over the place, it's going to take me about 5 times longer. I'm going to only fit 1/5 of the content on each line and page, (OK, 1/5 might be excessive, but the principle holds I feel).
Programming languages have similar properties. Why don't we always write integer instead of int, loop_variable instead of i, and have no compact way of writing unnamed lambda functions?
So this article is just the author complaining that he has no practice in reading mathematics. Would you be surprised if someone who never written a computer program before couldn't understand a complicated dynamic programming algorithm? Of course not, they have no practice or background!
And for the record, computer programming is much more precise than mathematics. Most people here don't do mathematics, so they don't realize how many implicit identifications we make between objects which are very very different. In programs, correct types are tantamount to the success of a program. In mathematics, we will readily identify rings with topological spaces and never think twice. Moreover, we need to readily be able to change the rules by which we consider two different things to be identical on the fly. It is simply a different way of thinking that programmers aren't used to.
Meyer's matrix analysis has an excellent, and relevant, quote:
The great French mathematician Pierre-Simon Laplace (1749–1827) said that, “Such is the advantage of a well-constructed language that its simplified notation often becomes the source of
profound theories.”"
If we ignore the cosmological constant contribution, for each of the 10 non-zero components of the Ricci curvature tensor, the sum of the component of the Ricci curvature tensor minus half of the corresponding component of the metric tensor multiplied by the Ricci scalar is equal to four times the ratio of the circumference of an arbitrary circle divided by its radius, multiplied by Newton's gravitational constant divided by the fourth power of the speed of light in vacuum and multiplied by the corresponding component of the stress-energy tensor.
Would this be clearer than the original [http://en.wikipedia.org/wiki/Einstein_field_equations]? After all, I don't use any weird symbols and avoid greek letters... Surely the author of that blog post would be satisfied by this ... Perhaps, I should include what I mean by Ricci curvature tensor ... but first define what I mean by a tensor, including the metric tensor, and explain other words like stress-energy tensor; it should not take more than a few lines of text for it to be completely clear, right?
Richard Feynman in one of his quantum physics lectures explains that he is going to abbreviate a few things because they are a pain to write out longhand on the chalkboard.
I think this is the main reason everything is so abbreviated, it comes from the era when doing lots of manual calculations by hand called for efficiency in notation over clarity.
This is an old chestnut. Mathematical notation is terse because mathematics doesn't consist entirely of notation! Look at any book or research paper; you'll find a great deal of text surrounding equations. Comparing this to code is nonsensical. Unless you're reading something in WEB, you are much more likely to encounter code than comments. There are certainly some unfortunate conventions and cruft in mathematics, but every generation of mathematicians rewrites in part what it inherited from its forebears.
The main reason it's hard to read math papers is because they contain complex, difficult ideas. Even professional mathematicians take a long time to read papers, and they usually won't be able to understand papers outside of their own specific field of math. I agree with the author that math papers could borrow some ideas from programming - explicitly defining all variables/functions, scoping, etc - but acquainting yourself with the conventions of the field alleviate most of those problems.
No doubt about it, mathematical notation can be difficult to read. It's terse, conceptually dense, operators are commonly overloaded, etc., etc.
But that's not why it's hard to read. Math is hard to read, I think, because math is hard:
(1) Some core mathematical concepts are fundamentally difficult. Notions like infinity (and different kinds of infinity!) are entirely foreign to our daily experience.
(2) In addition, mathematics is more abstract than most programming. Tim Gowers, in his lovely little book Mathematics: A Very Short Introduction, writes:
What is the black king in chess? This is a strange question, and the most satis-
factory way to deal with it seems to be to sidestep it slightly. What more can one
do than point to a chessboard and explain the rules of the game, perhaps paying
particular attention to the black king as one does so? What matters about the
black king is not its existence, or its intrinsic nature, but the role that it
plays in the game.
The abstract method in mathematics, as it is sometimes called, is what results
when one takes a similar attitude to mathematical objects.
This sort of abstraction is, I think, abhorred by many programmers. But it's the reason single-letter variable names are common in mathematics. There's no way to describe what a mathematical object is with a name relating it to some real-world, concrete, familiar thing, as programmers often try to do. You can only describe what it does by writing down some rules it obeys.*
(3) In math, concepts are inherently more hierarchical than is common in programming. As programmers, we're all familiar with building higher-level things from lower-level pieces. And we try, and often succeed, in building them up in ways that let other people use them without needing to know much of anything about the lower-level pieces. In math, there's a similar accretive process, but because the concepts are so much more abstract, it's often impossible to understand how a high-level concept behaves without understanding how its lower-level constituents behave. Mathematical concepts are conceptually hierarchical, whereas pieces of programs are often structurally hierarchical, but conceptually (nearly) orthogonal.
* — (A controversial aside.) An object-oriented mindset can exacerbate the problem by demanding that we reify concepts into objects that represent what they "are". This is often impossible, hence the inscrutable object names we've all laughed and despaired at.
Phil Karlton's well known witticism comes to mind:
There are only two hard things in computer science: cache invalidation and naming
things.
Naming things is hard because, just like in math, we sometimes lack a familiar semantic reference for the concepts we deal with as programmers.
Conversely, in functional languages, there's less need to think about what something "is", because the natural way of programming is to define relations (functions) on a small number of core data structures. Interestingly, single-letter variable names are also common in some functional languages, like Haskell, because it generally doesn't matter what the data is so long as you know what you can do with it. And that information is embodied in its type, expressed in its type signature, and enforced by the type-checker at compile time.
To your point on naming, the core of Hungarian Notation's thesis is that you can never get a name right, due to the creeping in of unfounded assumptions due to past experiences with that name, so you're doing more damage by trying. So, create a unique 3/4 letter nonsense tag (and define it), and get on with your life. Once you do this, it's crystal clear where the gaps in your understanding are, since if it looks like gibberish, there's a gap. And when you understand it, believe it or not, it doesn't look like gibberish. (Hungarian as originally defined, ie Apps Hungarian, not the horrible Systems Hungarian that came out of Programming Windows.)
It's a powerful yet under-appreciated idea. Of course the proof of the pudding is in the eating and so it does seem Hungarian takes it too far due to it's lack of success stories. But I can't help but think if that thread of an idea were not squished so resolutely that we'd be in a better place than we are now with the problem of naming.
> the natural way of programming is to define relations (functions) on a small number of core data structures. ...
> ... And that information is embodied in its type
If you encode information in type, you will have a very large number of data structures.
Hungarian notation for formulas would be terrible. It would make it that much harder to memorize, as well as increase the difficulty of seeing patterns between various formulas.
The real problem here is trying to force programming notation into mathematics notation. Programming variables emphasize what you're working with while mathematics variables emphasize ideas and relationships.
Math notation was't so much designed as accreted, and it shows in how awkward it can get. Dijkstra indirectly makes this point (among others) in "The notational conventions I adopted, and why" at http://www.cs.utexas.edu/~EWD/ewd13xx/EWD1300.PDF
[+] [-] aroberge|13 years ago|reply
Take Maxwell's equations for example. After learning vector calculus and becoming familiar with its notation, you notice how much meaning you can extract at a quick glance from the four Maxwell's equations expressed in differential form. The purpose is not to obfuscate the meaning (like the author implies when he mentions the Obfuscated C contest) but rather to reveal/encapsulate as much information as possible in a way that is easy to understand at a glance. You want to know what would happen if magnetic monopoles existed? Easy to do by just adding a few extra terms that are obvious by symmetry of the equations.
And, if you go beyond vector calculus, you can see an even clearer picture by writing
[+] [-] gnaritas|13 years ago|reply
Which is often the problem, it looks specific, but it really isn't; it's full of implicit assumptions about what the reader should know. It's not executable, because it's a language designed for being written by hand rather than executed by a computer.
However, the teaching of math would greatly benefit from an explicit executable form that makes no assumptions, i.e. a programming language. Gerry Sussman makes this case, he's pretty convincing.
[+] [-] forrestthewoods|13 years ago|reply
The language of math requires exact precision which makes extracting what the series of abstract symbols "mean" incredibly difficult. Trying to learn new mathematical concepts from wikipedia is damn near impossible. Here are two examples.
b-spline: http://en.wikipedia.org/wiki/B-spline spherical harmonics: http://en.wikipedia.org/wiki/Spherical_harmonics
Trying to figure out what those walls of symbols mean requires quite a lot of focus. Dig up source code for either and it's orders of magnitude easier to understand. The images for spherical harmonics conveys more meaning and understanding in a fraction of a second than spending 3 hours with a piece of paper and the equations would.
The language of math sucks.
[+] [-] darkxanthos|13 years ago|reply
2. It depends on context. The people writing and manipulating mathematical formulae LOVE the short hand I'm sure... but for consumers of the information perhaps it's less than ideal.
[+] [-] ColinWright|13 years ago|reply
There is no short cut. You can't write math like a novel, you can't read math like a novel. There are ideas that are deep and difficult, and unless you actually spend time working on the material you simply won't "get it."
Time and again I have explained to people something that's comparatively simple, and easily within their grasp. I've tried different approaches, different formulations, different arcs through the material, and time and time again the person has followed every step in detail, and just not "got it." There is no enlightenment, there is no sense of what's happening. It's only after they've invested the time that they have come to a sense of what's happening, and then the light dawns. Occasionally they say things like "Why didn't you explain it like that in the first place?" Then I point out that I did, but at that stage, they weren't ready for it.
It's like following a SatNav. You get to your destination having followed the turn-by-turn instructions, and yet, in truth, you really have no idea where you are. You have traveled from one local pocket to another local pocket, with no understanding of the space through which you've been.
Math is painful to read because you're trying to follow the turn-by-turn directions, instead of taking control of your own understanding and working to gain knowledge and insight, scope and intuition.
You won't understanding it without doing the work, and complaining that it's badly written is the smallest part of the problem.
[+] [-] Semaphor|13 years ago|reply
The same could be said for code that uses only single letter variables and functions.
It'd be a lot easier with readable variable names.
[+] [-] dxbydt|13 years ago|reply
People who do this:
and the second kind, people like me, who do this: You can easily guess that the 2nd kind are math majors. If my math professor started writing everything out in plain English like the first example, he'd never be able to cover a theorem per class. He'd still be writing the first lemma and the hour would be up.So he resorts to 1-character symbols, precise notations, and terse comments. The idea is - if the reader doesn't grok direct products or cyclic groups, he's fucked anyways, so why bother ? And if he does grok them, why impose cognitive overload by spelling it all out in great detail, just use 1-character symbols and move on.
Now both these styles are in direct conflict with each other, and in the Fortran/C/C++ community during the 80s-90s ( when every respectable programmer had a copy of Numerical Recipes on their desk ), you would emulate the 2nd kind.
In the 2000s & later, people got rid of their Numerical Recipes & exchanged them for "14 days to EJB" and "Learn Python in 21 days" and "Master Ruby in 7 days" and the like...the community started becoming a lot less math-y and a lot more verbose, and style 1 is back in vogue. Nowadays I get pulled up constantly in code review for using single character names....but I think this too will pass :)
[+] [-] barakm|13 years ago|reply
cyclicGroupOfDegree3 is a terrible name, unless you need to be really specific about degrees. cyclicGroup, please. (and I could imagine: cyclicGroup.degree() == 3)
dP is also a terrible name. My first thought goes to derivatives. directProduct is the right name. dProduct, dProd (if you like the Numerical Recipes style, expounded below) are better than dP, but still wrong for a library.
So first, let's assume directProduct is a library somewhere; maybe one you've even created. So let's reconstruct:
val z = directProduct(cg1, cg2)
Better, and more believable. And if the declarations of cg1 and cg2 are obvious (ie, the lines directly preceding) then you might have a case. I imagine directProduct(group1, group2) would actually be a happy medium. And if you use z in the next line or two, I'd let that slide.
The thing about Numerical Recipes is that often you're taking math syntax and coding it. Often doing so requires a good deal of commenting and temporary variables. One thing the book gets very wrong is it's function declarations (the function body is a separate argument) -- at the very least, rooted in a past of 80-character-lines and before code reviews. The first example in the book:
void flmoon(int n, int nph, long* jd, float* frac)
ought, in a modern era, be something like:
void MoonPhaseToDay(int n_cycles, int phase, long* julian_day, float* fractional_day);
If for no other reason than I can have some hope at understanding the second argument, or finding it again. You'll also notice flmoon is a misnomer -- it computes more than full moons!
[+] [-] kd0amg|13 years ago|reply
This case analysis works if you only consider people who've been sitting in on the class the whole time, but someone who appears mid-way through the semester (or analogously, starts looking at some project's code without having been involved in its development) may understand group theory and still have trouble following the lecture.
// Compute the direct product of 2 cyclic groups
I would much rather give the function a name that describes its purpose (and give a full description in a comment at the function's definition) than annotate every use of the function.
[+] [-] cwills|13 years ago|reply
Programming with descriptive and meaningful variable / function names that have intrinsic meaning skips this step: 'wait, what was the cg2 again? let me waste time by looking back through the code and figuring that out again'. Particularly for others reading your code later.
But I try to fit somewhere in between the two examples you've shown, meaningful but not too long -> the benefits of longer variable / functions names diminishes when names get too long as variable names tend to blend together (see law of diminishing returns).
[+] [-] Xcelerate|13 years ago|reply
I realize you've got a comment above it, but if you really code like that then you are very different from any code I've come across where the programmers used short, non-descriptive variable names.
As my coding has improved over the years, I've gone from an imperative, abbreviated variable style to a functional, long-named variable style. Even with the long names, my code is MUCH more readable and it's still about 2x less typing than the imperative style!
(Also, I don't think all math majors use that second style).
[+] [-] alter8|13 years ago|reply
[+] [-] j2kun|13 years ago|reply
[+] [-] gfodor|13 years ago|reply
When you are looking at an equation, you are looking at the purest distillation of an idea. Underneath that equation sits countless layers of abstraction and reasoning. Why can't I peel back these layers and see them on my computer or iPad? The equation is the iceberg tip peeking out of the water onto the paper, I want to see underneath. Let me feel around and slowly and confidently fill in the places where my understanding is fuzzy. Prevent me from moving back up to the final equation until everything underneath is fleshed out and solid in my mind. And if bits start to fade, let me quickly react to snap them back into focus.
This is what we are doing mentally anyway when we flip back and forth in a math text referencing previous proofs and equations. Math needs it's "hyperlink."
Anything I say here has been said better and more convincingly by Bret Victor:
http://worrydream.com/KillMath/ http://worrydream.com/LadderOfAbstraction/
Though I will argue that at least in his Kill Math writings he's throwing the baby out with the bath water in a certain sense. Let's keep the symbology as a optimal way to encapsulate our knowledge for the amazing mental leverage it gives us, but give us a way to move up and down the ladder of abstraction in order to facilitate understanding.
[+] [-] trhtrsh|13 years ago|reply
[+] [-] lutusp|13 years ago|reply
To a mathematician reading the technical literature from his own field, there's no issue with math notation. Problems sometimes come up when a specialist in one field tries to read literature from a different specialty -- but that's true in computer programming too.
This may come as a surprise, but math notation is much more uniform than computer-science notation, including all the efforts to create generic program listings. Mathematicians are reluctant to invent new symbols, but it's sometimes necessary.
When I read computer program source code, I often wish the programmer had summarized the meaning of the code using math notation. I guess that puts me in a position precisely opposite that of the author.
[+] [-] btilly|13 years ago|reply
Let me guess. You haven't learned much differential geometry?
Constants vary by 2 pi depending on which definition you use. Functions might come before or after their arguments. And, of course, you leave everything that is "unambiguous" out of the notation. (Proving that it truly is unambiguous is sometimes nontrivial for the novice.) Guessing what notation a particular author is using has been known to be daunting, even for other differential geometers.
In grad school I remember sitting down with homework sets and spending longer working out what the question said than I did in solving it once understood.
That said, if you tried to actually write everything out explicitly, it would be impossible to read anything. Compact notation is a necessary evil - without it your brain simply can't think certain things. With it, it is hard for anyone else to figure out what you just said.
[+] [-] ahallerberg|13 years ago|reply
[+] [-] vecter|13 years ago|reply
In other words, math is a language for formalizing intuition which, when finally written, unfortunately removes all traces of intuition and leaves only the end result of the thinking, not the path that it took to arrive at the critical insight.
[+] [-] yaks_hairbrush|13 years ago|reply
I had a graduate probability teacher who said (paraphrased) "one of the beautiful things about math is that you start with a definition, and you prove some very simple things with the definition... so simple that you feel you're just using circular reasoning. Then you find that your definition is equivalent to a useful property!"
Actually, what happened when the stuff was developed is that someone wanted the useful property, and managed to rationalize a definition which fit. (example: group theory was done for hundreds of years before we had a definition of group. Noether noticed that a lot of folks were writing the same sorts of things in different contexts, so she distilled it down to three axioms.)
For a really concrete example, consider ordered pairs. A person being coy about their intent would say that "we define an ordered pair (x,y) on a set S as a set of the form {{x},{x,y}}, where x and y are in S."
It's safe to say that no one thinks of an ordered pair in that fashion. The intent was to have two ordered pairs be equal if and only if each of the two coordinates are equal. You can prove this from the above definition, but it's far more helpful to tell the audience in advance that we really want a structure with this property.
[+] [-] bennyg|13 years ago|reply
[+] [-] ggchappell|13 years ago|reply
So: notation is a wonderful thing. If someone can improve on it, then great, but modern math notation is what makes math doable. It's true that there is poor notation and poorly used notation; these things need to be fixed.
Regardless, I agree that math is hard to read. I read a lot of math. It's hard. Part of this is because it involves abstract, complicated stuff that often must be understood exactly. But part is because we are not very good at writing it. Or perhaps we don't put as much effort into making it readable as we should.
Being someone who knows a fair amount about programming (or so I like to think) and also writes math research papers, I've found that some of the concepts used to manage complexity in software are also applicable to math.
In particular, I must agree about scope. I've made an effort in my recent writing to be careful about this issue. Another helpful idea involves how to write good comments in code. Too many mathematical proofs perform some operation without telling the reader why or giving any kind of overview. There is nothing wrong with saying, "Here's what we're going to do," and then doing it, and then saying, "Here's what we just did."
[+] [-] nn2|13 years ago|reply
And a lot of papers do not even bother to explain some variable but just assume the reader already knows it. One of the earlier commenters made this mistake very prominently enthusing over Maxwell's equations.
Yes of course the formula looks better shorter when you already know what it means. But that completely misses the point that it was written down to explain it to someone who doesn't already know what it means. If you already do you're the wrong target audience.
Longer variable names would help. Or for online paper just have a tooltip that opens the paragraph that explains what the variable mans when you hover over it would also help a lot.
Or maybe some color coding to easily find it (there was a recent link here recent explaining FFT which used this trick very successfully)
But I guess most Mathematicians don't bother because they only write for a small circle of colleagues anyways.
[+] [-] modarts|13 years ago|reply
You have to understand the physics behind the equations (what's charge? what's an electric field) as well as the mathematical structure (what's a vector space? what's a line integral?) in order to make use of them. They are equations used to answer questions like "What happens to the strength of this magnetic field if I increase the velocity of this charged particle responsible for generating it"? They aren't meant to be explanatory (but have the beautiful side-effect of explaining how light propagates in a vacuum.)
[+] [-] Xcelerate|13 years ago|reply
For a REFERENCE, you can just list the equations in their most commonly used form.
[+] [-] tokenadult|13 years ago|reply
http://www.math.uga.edu/~azoff/courses/halmos.pdf
by the late Paul Halmos, a mathematician famous for his clarity of writing, suggests procedures for making mathematical papers less painful to read.
[+] [-] glomph|13 years ago|reply
[+] [-] john_b|13 years ago|reply
The notion of scope as an integral part of mathematics is a particularly interesting suggestion. Mathematics is the study of abstract, quantitative truths (and falsehoods), and these truths, being universal, have universal scope (although you can constrain some truths as special cases of more general truths, but I doubt this is what the author had in mind). To consider this a problem indicates that the author is searching for a tool rather than a way of thinking.
"Math is such a cognitive overload of operators" because it succinctly describes a great deal of action. A program in a conventional language like C might take a hundred lines to describe what could be described in a handful, using some mathematical notation. If you want a programming example, just look at the average length of an APL program vs the average length of a Javascript or C program.
Math is inherently hard. So is programming. Not many people can do either very well. Even fewer can do both very well. The notations of math are meant to be flexible because math is a tool for discovering new ideas and analyzing their properties. Programs are meant to accomplish some real world task. Criticizing the language of one solely from the perspective of the other is not a useful activity.
[+] [-] kd0amg|13 years ago|reply
The scope issue is not just for theorems. In programming, scope is about what meanings get bound to what symbols, whether those symbols are types, operators, data, etc. Even in math, we can see a notion of "binding" vs. "bound" vs. "free" occurrences of a symbol: seeing something like "∀x∈N.x+k≥0" would make me think "Ok, I see what `x' is, but what's this `k'?" Treating every definition like it's at top-level makes for unreadable code and unreadable math. Ever had to search back through a document looking for the definition of some notation only to find it buried in an earlier proof of an unrelated theorem without so much as a "Definition: …" marker? I would much prefer not to have to do that again.
Transferred to another domain, "Why should we need scope? What good would that do?" becomes "Why should pronouns have antecedents? What good would that do?" It is important to acknowledge that mathematical notation is also a tool for explaining the ideas one has discovered with it.
[+] [-] ryankey|13 years ago|reply
[+] [-] gknoy|13 years ago|reply
I think that yes, they are: for centuries, mathematics has been written by hand. It's much easier to write 'f' than 'force'. on a blackboard. Moreover, when writing on paper, with ink that you have to make or buy, with a pen that wears out as you write with it, it makes sense that early mathematicians would embrace a compressed notation. Scribes even did it, so it shouldn't surprise us that mathematicians would.
The compression is based on domain knowledge, and this is only problematic for people who are not intimately familiar with the domain at hand. Physics is similar. Decoding the rocket equation is only possible when you know what m1 and m0 are, or ve, and many properties, constants, and even operations are symbolized with a single greek letter. (Gradients, for example)
This is very powerful, because (as others have mentioned) it allows you to easily write more-complex things, and often times you (as a mathematician or physicist) prefer to think at a higher level of abstraction. It also makes it tremendously arcane for those of us who don't even know the names of the greek letters, let alone have a sound backing in that particular field of math or physics.
[+] [-] CJefferson|13 years ago|reply
It's all about the amount of mental power and work you have to exert. If I'm filling a few pages with equations, if I have to write 'force' instead of 'f' all over the place, it's going to take me about 5 times longer. I'm going to only fit 1/5 of the content on each line and page, (OK, 1/5 might be excessive, but the principle holds I feel).
Programming languages have similar properties. Why don't we always write integer instead of int, loop_variable instead of i, and have no compact way of writing unnamed lambda functions?
[+] [-] j2kun|13 years ago|reply
And for the record, computer programming is much more precise than mathematics. Most people here don't do mathematics, so they don't realize how many implicit identifications we make between objects which are very very different. In programs, correct types are tantamount to the success of a program. In mathematics, we will readily identify rings with topological spaces and never think twice. Moreover, we need to readily be able to change the rules by which we consider two different things to be identical on the fly. It is simply a different way of thinking that programmers aren't used to.
[+] [-] b_emery|13 years ago|reply
The great French mathematician Pierre-Simon Laplace (1749–1827) said that, “Such is the advantage of a well-constructed language that its simplified notation often becomes the source of profound theories.”"
[+] [-] aroberge|13 years ago|reply
Would this be clearer than the original [http://en.wikipedia.org/wiki/Einstein_field_equations]? After all, I don't use any weird symbols and avoid greek letters... Surely the author of that blog post would be satisfied by this ... Perhaps, I should include what I mean by Ricci curvature tensor ... but first define what I mean by a tensor, including the metric tensor, and explain other words like stress-energy tensor; it should not take more than a few lines of text for it to be completely clear, right?
[+] [-] narrator|13 years ago|reply
I think this is the main reason everything is so abbreviated, it comes from the era when doing lots of manual calculations by hand called for efficiency in notation over clarity.
[+] [-] sbi|13 years ago|reply
[+] [-] Jimmy|13 years ago|reply
[+] [-] pash|13 years ago|reply
But that's not why it's hard to read. Math is hard to read, I think, because math is hard:
(1) Some core mathematical concepts are fundamentally difficult. Notions like infinity (and different kinds of infinity!) are entirely foreign to our daily experience.
(2) In addition, mathematics is more abstract than most programming. Tim Gowers, in his lovely little book Mathematics: A Very Short Introduction, writes:
This sort of abstraction is, I think, abhorred by many programmers. But it's the reason single-letter variable names are common in mathematics. There's no way to describe what a mathematical object is with a name relating it to some real-world, concrete, familiar thing, as programmers often try to do. You can only describe what it does by writing down some rules it obeys.*(3) In math, concepts are inherently more hierarchical than is common in programming. As programmers, we're all familiar with building higher-level things from lower-level pieces. And we try, and often succeed, in building them up in ways that let other people use them without needing to know much of anything about the lower-level pieces. In math, there's a similar accretive process, but because the concepts are so much more abstract, it's often impossible to understand how a high-level concept behaves without understanding how its lower-level constituents behave. Mathematical concepts are conceptually hierarchical, whereas pieces of programs are often structurally hierarchical, but conceptually (nearly) orthogonal.
* — (A controversial aside.) An object-oriented mindset can exacerbate the problem by demanding that we reify concepts into objects that represent what they "are". This is often impossible, hence the inscrutable object names we've all laughed and despaired at.
Phil Karlton's well known witticism comes to mind:
Naming things is hard because, just like in math, we sometimes lack a familiar semantic reference for the concepts we deal with as programmers.Conversely, in functional languages, there's less need to think about what something "is", because the natural way of programming is to define relations (functions) on a small number of core data structures. Interestingly, single-letter variable names are also common in some functional languages, like Haskell, because it generally doesn't matter what the data is so long as you know what you can do with it. And that information is embodied in its type, expressed in its type signature, and enforced by the type-checker at compile time.
[+] [-] gfodor|13 years ago|reply
It's a powerful yet under-appreciated idea. Of course the proof of the pudding is in the eating and so it does seem Hungarian takes it too far due to it's lack of success stories. But I can't help but think if that thread of an idea were not squished so resolutely that we'd be in a better place than we are now with the problem of naming.
[+] [-] trhtrsh|13 years ago|reply
> the natural way of programming is to define relations (functions) on a small number of core data structures. ... > ... And that information is embodied in its type
If you encode information in type, you will have a very large number of data structures.
[+] [-] ryankey|13 years ago|reply
The real problem here is trying to force programming notation into mathematics notation. Programming variables emphasize what you're working with while mathematics variables emphasize ideas and relationships.
[+] [-] jdougan|13 years ago|reply