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

Why math is painful to read

matusiak.eu

Post reply on HN
Print view View original

31–40 of 106 posts

Re: Why math is painful to read

#31

Post by ggchappell »

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

Re: Why math is painful to read

#32

Post by darkxanthos »

aroberge wrote: post #6

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

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.

Re: Why math is painful to read

#34

Post by davegauer »

michaelochurch wrote: post #10

Disagree strongly. Math is often the easiest and simplest thing that works for the class of problems it exists to solve. Imagine trying to explain singular value decomposition without the notion of a matrix. No group theory, no well-formed concept of a linear transformation or function . You wouldn't be able to do it. No one even had such ideas before generations of mathematical machinery had been built. I've come to…

I think you make a really good point about the power of mathematical notation and conventions.

However, I completely agree with the article.

Do mathematical formulas have to use Greek letters rather than useful variable names like "distance" or "speed"?

Does C's syntax actually allow you to express something you can't in Python? Or is it more terse for historical reasons? (And never mind that it's a good idea to use descriptive variables and function names in either language!)

I think the keyboard-driven vs GUI tool analogy is very apt. vi is very powerful. Would the average user like it much if we made vi the interface for all text forms in browsers? I think sometimes it's desirable to present a friendlier form of a thing. (You obviously agree regarding web programming.)

So I think the complaint is this: why is math always expressed in the tersest form? Is it really necessary?

Why does math have to be restricted to the lifers!?

Re: Why math is painful to read

#35

Post by 73939133 »

I never posted before but this article made me so mad I had to jump into the comments!

I am so glad to find everyone pointing out all the reasons the article is wrong, actually there is a highly relevant link on math.stackexchange about this particular issue:

http://math.stackexchange.com/questions/24241/why-do-mathema...

Re: Why math is painful to read

#36

Post by gknoy »

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

Re: Why math is painful to read

#38

Post by gfodor »

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:

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.

Re: Why math is painful to read

#39

Post by b_emery »

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

Re: Why math is painful to read

#40

Post by barakm »

dxbydt wrote: post #23

Frankly, there are 2 kinds of programmers. People who do this: 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 nev…

That's kind of a strawman argument.

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!

Post reply on HN