Hacker News new | ask | show | jobs
by jstanley 2157 days ago
> Math notation sucks because none of it maps to things non-mathematicians know.

This doesn't mean maths notation sucks any more than vim's user interface sucks because it doesn't make sense to non-vim-users.

Mathematical notation presumably mostly makes perfect sense to the kind of people who deal with mathematical notation all day long.

3 comments

The question is if we should optimize for pencil efficiency or education. To me, it's obvious: I've met way more people interesting in learning math than performing it, so we try to make notation as clear and possible.

Vim, like math notation, is optimized for efficiency. That's great for power users, but it's not what you would use if you wanted to teach someone how to word process.

(BTW, try imaging Vim where each file mandates its own special keybindings. That's math notation for ya.)

Vim, like math notation, is optimized for efficiency. That's great for power users, but it's not what you would use if you wanted to teach someone how to word process.

Vim is a text editor, not a word processor. Additionally, Vim is a tool designed for power users. Mathematical notation is also meant for power users. When we teach mathematics, we introduce the notation gradually, so students have time to pick it up. This is a process which takes decades from Kindergarten through PhD. Just as a Vim user would scoff at being forced to write in Notepad, a mathematics PhD would scoff at being forced to express their ideas in Kindergarten-level mathematical notation.

try imaging Vim where each file mandates its own special keybindings. That's math notation for ya.

That's how Emacs works, and how Vim works when you install filetype-specific plugins.

I'm a power user (been programming for 30 years) and I refuse to use vim keybindings.

I have too many things to remember, and there are plenty of options that give me equal power but don't demand that investment from me.

Math isn't like that - I do more math than the average person and I hate having to decipher the annotation. The number of times I've tried to work out if this sigma is the same as the sigma in this other paper frustrates me enormously.

Or the paper that used a accuracy^bar metric as their primary reporting metric, and we couldn't get near it until we found an obscure footnote in an appendix that explained the ^bar metrics were temporally averaged at test time around a known labelled standard (ie, test data was used to optimise the performance).

Mathematics is more general and applicable than Vim, I'll give you that. I wasn't the one who brought in the Vim analogy, however.

It seems like your complaints are with academic papers, not with mathematical notation specifically. This is a problem that is universal to academic papers. Try reading a critical theory paper, for example, and you'll find it's extremely dense with critical theory jargon the authors don't bother explaining at all.

The problem with academic papers is that they aren't intended for a general audience. The authors of papers are often operating in subfields that are so small that they've actually met most of the other people who will be reading their papers. In that situation, conventions and jargon arise naturally among colleagues. Variable names form a part of these conventions such that, in a more common example, sigma will mean standard deviation among statisticians but mean singular value among linear algebraists.

The other problem with academic papers is that the authors generally don't care about reproducibility, consistency, clarity, pedagogy, or even intelligibility. They're optimizing for quantity of papers published, not quality. As long as their expert peer reviewers understand and give the green light for publication, that's good enough.

To be honest I think my (and most people on this thread) real complaint isn't with notation per-say (as in Euclidean vs Hilbert notation etc, as discussed by Tao).

It's really about the lazy habits of many who work at the intersection of math and computer science, and use maths to express themselves without defining things.

> The other problem with academic papers is that the authors generally don't care about reproducibility, consistency, clarity, pedagogy, or even intelligibility. They're optimizing for quantity of papers published, not quality. As long as their expert peer reviewers understand and give the green light for publication, that's good enough.

Having worked around this field, I think this (common) perception of publishing doesn't quite capture what is happening. Peer review isn't anything like code review, and software engineers (separate from computer scientists and mathematicians) think that it is.

(Irrelevant nit: the phrase is "per se", meaning "by virtue of itself" in Latin.)
You say "I've met way more people interesting in learning math than performing it", but I have found it downright impossible to learn mathematics without performing it. And I daresay this is true of most people -- a well-known feeling amongst mathematics graduate students is to read a chapter of a text, think we have understood it, then turn to the very first exercise and get completely stumped and have to backtrack.

A lot of mathematics is optimised for pencil efficiency for a reason, and it's not at odds with learning mathematics.

> I've met way more people interesting in learning math than performing it, so we try to make notation as clear and possible.

That is like trying to learn an instrument by looking at it but never touching it. Notation like other tools is made to useful. Also if you never played an instrument you would think they are each their own little completely different world. That's totally wrong for ya.

> This doesn't mean maths notation sucks any more than vim's user interface sucks because it doesn't make sense to non-vim-users.

I think this nails it perfectly. There are plenty of good programmers who refuse to use vim. In math those people can't operate.

> Mathematical notation presumably mostly makes perfect sense to the kind of people who deal with mathematical notation all day long.

Maybe the overuse of opaque names leads to self-selection of who becomes a mathematician?

Single-letter non-descriptive variable and functions names would “make sense” to programmers who use it all day long too — but that alone doesn’t make it a good idea.

If your job consisted of calculating with sequences of changes of programs, with no copy paste available, you'd probably feel differently. For example, a fairly roundabout derivation of a change of base for logarithms (pretending we forget log(a^x) = x log(a) for arbitrary base):

We're trying to derive that a^x = b^(x * log_b(a)).

Or in verbose descriptive terms, oldBase `exponentiate` oldExponent = newBase `exponentiate` ( oldExponent `multiply` inverseExponentiationInNewBase (oldBase) ).

We could maybe argue about the verbosity and clarity of each statement, but I think math's notation shines when you compare derivations instead of statements:

      a^x
    = b^( log_b(a^x)       )
    = b^(    ln(a^x)/ln(b) )
    = b^(  x * ln(a)/ln(b) )
    = b^(  x * log_b(a)    )
or with descriptive names (apologies to readers on mobile):

      oldBase `exponentiate` oldExponent
    = newBase `exponentiate` ( inverseExponentiationInNewBase(oldBase `exponentiate` oldExponent)                                                )
    = newBase `exponentiate` (   inverseNaturalExponentiation(oldBase `exponentiate` oldExponent) `divide` inverseNaturalExponentiation(newBase) )
    = newBase `exponentiate` ( oldExponent  `multiply`  inverseNaturalExponentiation   (oldBase)  `divide` inverseNaturalExponentiation(newBase) )
    = newBase `exponentiate` ( oldExponent  `multiply`  inverseExponentiationInNewBase (oldBase)                                                 )
If I were doing it by hand, I know I'd screw it up with long stuff to copy. Remember accidentally dropping negative signs in school? Hell, I'm still not really sure I got the second version right. By hand, I'd also get super frustrated and impatient writing sooo much.

This is a ridiculous over the top example, since I'm avoiding using everyday symbols like * and / and ^ and log, but for working mathematicians and applied mathematicians, their notation is just as familiar to them and I'm sure it'd be equally annoying to write out descriptively as it is for us to write out basic math symbols descriptively.

Programming notations are to be written and read. Math notation is to be manipulated.

Every domain — every language — has its basic jargon, and algebra is no exception. I’m not suggesting that mathematicians simply replace every symbol with a word that hints at meaning; that’s too literal an interpretation of what I wrote. “exponentiate” is no more descriptive than “^”.

But there are alternative ways of describing that derivation that are not as symbol-manipulation heavy; you would certainly not communicate this proof in words to another mathematician — or to a non-mathematician — by simply reading your derivation (or your alternate, verbose derivation) symbol by symbol. Instead you would more likely rely on the meanings of the symbols.

Even in your verbose derivation, however, it’s worth noting that your new names capture the fact that b^x and log_b(x) are inverses, a key piece that someone unfamiliar with logarithms and their relationship to exponentiation now has a hope to understand.

I think most people who wanted to communicate this proof in person would say 'let's find a whiteboard, or do you have some paper'? And then proceed to write down the first version of the proof.

Because it is better communicated in notation than in words.

I'm both a programmer and a mathematician. Mathematics is written in English (or another human language) plus added symbols. The symbols are what we refer to as the notation. It's not comparable to programming language. Here the words are equal to the symbols.

Also, no better notation could help you understand most modern mathematics. There's no better choice of symbols or names that will help you understand Galois theory. You simply need to understand high-school algebra, then group theory, then Galois theory.

> There's no better choice of symbols or names that will help you understand Galois theory. You simply need to understand high-school algebra, then group theory, then Galois theory.

This probably isn't completely true—as will be clear to anyone, even a subject expert, who tries to go back and read the original papers. At least part of this is due to fads in notation—in my field, I can easily read the papers of people who do similar work to mine, and struggle with the papers of those who don't, even when they're talking about exactly the same thing—but some of it must be due to genuine improvement.

Yes, you're right. I should have said, there's no better choice of symbols that will remove the huge set of prerequisites you need to first understand. There isn't as large of a tower of abstractions to understand most codebases.
but put it the other way: can you contrive some extremely bad notation to make it harder to understand Galois theory?
Opaque names have the advantage that they don't trigger any potentially misleading associations and they emphasize the abstract nature of what is being discussed. A variable named x could be anything, even something that the mathematician/programmer didn't anticipate.
I agree with this. Additionally, I think a lot of detractors of single-letter variable names don't realize that it is often the case that the structure of the equation/expression is what's interesting, not what any individual variable represents. That structure is most visible and apparent when the variables don't take up any more space than the operators.

Being able to recognize things like "oh, that's a polynomial!" is extremely useful, especially in the context of learning new math rather than a more applied context. And I think it would be extremely hard to spot an opportunity to do integration by parts when working with Java-style verbose variable names.

>Single-letter non-descriptive variable and functions names would “make sense” to programmers who use it all day long too — but that alone doesn’t make it a good idea.

Imagine you would write the code on paper by hand and have to repeat some long var or function name all the time . Even with IDEs I see programming languages using shorter keywords like "var","const","int" then the full word.

Because you are agains single letter symbols let me know what are your suggestions for PI, or X(in polynomials or equations) and show me a screenshot on how some real world physics equation solving would look like with camel case named symbols.

Go back a few centuries and you get long form Latin instead. Or go back much further and you will find the quadratic formula described as taking the number that the second term is increased by, diminishing it by half and then.... . Basically an essay just to say -q/2.

Sure, you could write

-CoefficientInFrontOfXToTheOne/2

But then each row of your calculation will need line breaks and will be hard to understand. It will take forever to write and it will take forever to read. No thank you.

Mathematicians will never agree to write dblEulerConstant instead of e.
And, issues about the length of the name aside, we shouldn't! `e` isn't a double or any other standard numeric type. It is an infinite-precision number.
I know what you mean, and a number that is not infinitely precise is an interval (i.e. a set of numbers). e is a number that is quite hard to pin on the imaginary number line, because the chances of hitting it with a pin is virtually zero. But the same argument can be made about the number 2 or 3. Those are just notations to abstract ideas, even though it is easier to formulate analogies for some of those numbers.

Now, formalising that above sentence even with symbols is quite difficult.