The Grammar According to West | Hacker News Reader

The Grammar According to West

dwest.web.illinois.edu

65 pointssurprisetalk26 comments

As a non-native speaker, another tip I remember reading somewhere and then finding it very useful: when you read a packed sentence that doesn't seem super clear and the next sentence starts with "Indeed, ..." that means you should read further as it will be a kind of explanation or elaboration. I mostly filtered out such words as "filler" or generic "emphasis words", but they guide the understanding also.

Good mathematical writing has this kind of cadence and pattern to it, and that's not a problem. For good writers some personal charm and flavor can still shine through, but it helps the reader to use the familiar trope structures. Unfortunately, this kind of "meta" is not taught much, so many students don't quite understand how to read math books, get frustrated when they progress slow, expecting to read it at the same speed as a history book or a novel. In a math book it's normal to re-read sentences or jump back half a page, to flip the pages back and forth, to put down the book for a moment and think etc. and it may take an afternoon to just digest one or two pages.

In general, it has been my experience learning foreign languages as an adult that every time somebody or yourself dismiss a word as meaning nothing or adding nothing to a sentence, you haven't understood it properly -- !especially! if native speakers dismiss it also.

I vaguely remember that Prof Thomas Körner in Cambridge used to have some good notes on mathematical writing. I can't find them now but here is another lecturer's notes that look quite good: https://www.dpmms.cam.ac.uk/~grw46/Writing_Guide.pdf

Paul Halmos and Donald Knuth are good examples of people that have a very nice mathematical style imo.

It may be his notes on the Cambridge Part III essay, which contain a lot of insights about mathematical writing that generalize beyond writing the Part III essay, naturally with his trademark wit: https://www.dpmms.cam.ac.uk/~twk10/Essay.pdf

I will always be grateful to Prof Körner for advocating that people who did Part III retroactively get awarded MMath masters degrees, thus making the most hardcore year of my academic life at least somewhat comprehensible to people outside Cambridge.

That's the one, thank you. Likewise about the MMath.

You encounter abusive language/notation basically everywhere in math. Open up a calculus/real analysis textbook. A lot of the old ones write sequences in the curly brace/set {x_n} notation:

"let {x_n} be a sequence"

As the author points out, a sequence is a function. The statement {x_n} is the set of terms of the sequence, its range. A function and its range are two different things. And also sets have no ordering. It might seem like a minor thing, but I thought we were trying to be precise?

A second example: at the high school level, I'm pretty sure a lot of textbooks don't carefully distinguish between a function and the formula defining the function very well.

The author of this web page has a section on what he calls "double duty definitions". Personally, I don't find anything wrong with the language "let G=(V,E) be a graph". G is the graph and we're simultaneously defining/naming its structure. So, some of this is a matter of taste. And, to some extent, you just have to get used to the way mathematicians write.

Right, the notation of derivatives is also totally confusing, especially for things like the chain rule. The sloppy way to write it seems very intuitive but isn't precise. To write that in a precise way, you have to use the vertical-bar-on-the-right (e.g. d/dx f(x) | x=0, but typeset properly), variable names etc. In high school I rewrote a lot of the textbook stuff in a super explicit version for myself like this and it got very verbose of course, but gave deeper understanding.

Same in college when learning the Fourier transform, a stumbling block was that the prof didn't properly explain that it takes a function as a whole and gives a whole new function as output. When you first learn this concept, it's a bit of time to wrap your head around, but when it clicks, everything makes more sense. But just writing F{sin(x)} = ... seems like F acts on a concrete value. A more explicit way would be F{x->sin(x)}={x->...}

Of course once you already know these fundamentals and they are baked into your brain and take them for granted, it's hard to see where beginners get confused, and writing in short hand is so much easier so you get sloppy while still unambiguous to experienced people.

This is why I always preferred to see coded-up demos and implementations as opposed to formulas on blackboards and slides. If you have to implement it, you can't handwave away things as pedantry. It forces precision by default.

Fully agree with this thought. Sloppy notation has been a hindrance to my personal understanding many times. Math made more sense for me when I could code it up and see the function doing things. Everything explicit vs inconsistent shorthand that saved the author a few pen strokes.

Which is why I am so favorable of Jupyter notebook-like teaching environments. Embed the (guaranteed to execute!!! no illegal shorthand) code so that learners can get a true representation that can be manipulated. Although, I think they are still unlikely to reshape education - now you require some coding fluency + the niche math topic.

I think there's also a bit of sneakiness in that by not requiring actual understanding, it's possible to memorize equations and pretend to understand, and then pretend that students got more understanding than in reality.

In programming you would put function as a parameter. So, maybe something like this

F{sin}(x) = ...

is just as short and clearer?

Yes, but often the formula is more complicated like (sin(x) + 5)^2.

> abusive language/notation basically everywhere in math

In most cases it is not as much abusing notation as overloading it. If you think of the context of a formula (say, adjacent paragraphs) as its implicit arguments (think lambda captures in c++), then it is natural that curly braces can denote both a set and a sequence, depending on this implicit input.

Such context dependent use of symbols is actually rather convenient with a little practice.

"it is natural that curly braces can denote both a set and a sequence, depending on this implicit input."

I don't even know where to begin. Overloading symbols in mathematics occurs all over the place. There's nothing wrong with that. The difference between overloading a symbol and abusing it is whether there is an agreed upon definition/convention regarding its use and to what extent its use conforms to that definition/convention. What I'm saying in my original post is that the statement "{x_n} is a sequence" disagrees with the formal idea of what a sequence is and that most writers don't bother to explain their own notational use.

If you wish to re-define the curly braces to have a context-dependent meaning, knock yourself out. But, I would imagine that that practice would confuse a lot of people. Math is a human activity. It's not a programming language.

I remember being very pleased when I first encountered what might be an abuse of notation, but is nonetheless super convenient: \Sum_{s \in S}, where s is an element of a set S. Or, even better, just: \Sum s_i. Of course, this is defensible as I was writing out 100 summations in a stats course, not writing teaching material.

My guess is that most mathematicians wouldn't consider that notation abusive. Why do you think it is? That notation is a convenience that allows us to represent a sum over a set where the elements aren't indexed by integers. So, in this particular case, I think there is a utility to the notation. And also: the definition of \sum_{e\in S} is ubiquitous.

I'm not a mathematician, but I went decently far into math and hardly ever encountered a summation over non-indexed elements, or really anything beyond the standard \Sum_{i=1}^{n}, even up to my final math courses.

I wasn't aware of its ubiquity! I may only think of it as "abusive" due to lack of familiarity. The way I've seen it used is: \Sum_{e \in S} e_i, where 'i' is never explicitly defined, and this still assumes elements indexed by integers. The only utility seems to be from the abbreviation, leaving out the range of indices being iterated over. Not saying that isn't useful, but the rigor of the math probably doesn't benefit from time-saving omissions.

> \Sum_{e \in S} e_i

I'm tempted to call that notation simply wrong instead of abusive. Generally "abusive" notation, while technically wrong, has some redeeming feature in intuition or consicebess.

In this case, the alternative notation would be to simply drop the index and write "\Sum_{e \in S} e", which seems to be all around better.

From having spent way too much time doing technical writing; I'm tempted to say the notation you are recalling really was a mistake. They probably started out with "\Sum_{e \in S} e", then decided to make all summations be index based instead of set based. Unless you spend a lot of time proofreading, that type of style change can easily lead to half translated expressions like what you recall.

> Note the difference between "where" and "such that". "Where" is used when the preceding notation is being defined; "such that" is used when it is already defined and its value is being restricted.

I found this interesting. SQL and Swift use “where” for restrictions. Any other examples in programming languages?

If a programming language wanted to use a keyword for restrictions that isn’t “where” (and still is a single word, hence “such that” doesn’t qualify), what word would be suitable instead? “With”? “Having”?

LINQ uses "where".

As for single-word alternatives, "if" is common. For example, in Python:

    >>> [(x, y) for x in range(10) for y in range(2, x) if x % y == 0]
    [(4, 2), (6, 2), (6, 3), (8, 2), (8, 4), (9, 3)]

Common Lisp uses "if" but also uses "when":

    * (loop for x from 1 to 100 when (= x (expt (floor (sqrt x)) 2)) collect x)
    (1 4 9 16 25 36 49 64 81 100)

Perl and Common Lisp both use "unless", of course with the sense inverted:

    DB<4> for (1..10) { print "$_ " unless $_ == int($_**.5)**2 }
    2 3 5 6 7 8 10

SQL uses both "where" and "having". You could also reasonably use "suppose", "stipulate", "assert", "wolog", or "let". Lisp M-expressions (and, arguably, Dijkstra's guarded command language) used "→".

For my second question I was actually more thinking of value constrains as type annotations. For example, something like

    struct S
    {
        x : num;
        y : num;
        where x < y
    }

Meaning the compiler would statically verify that x < y for all instances of S at all times. Alternatively, you could also have:

    struct S
    {
        x : num;
        y : num;
    }

    let s : S where s.x < s.y;

to only restrict a specific variable.

"If" wouldn't fit that use case, and neither would "when". I suppose "require" would work, but it also feels different from "such that". The intended meaning of the latter example would be "let s be an S such that s.x < s.y". "Given", as the sibling comment by hallole proposes, also doesn't fit.

A very interesting idea! A couple of functional languages use "when" in a similar way to introduce pattern-matching guards, but I haven't used any languages which support such a general facility for type declarations, though I suspect some dependently-typed languages do. I suppose that at least you would need to limit the condition to terminating computations to be able to verify it at compile time, and perhaps restrict mutation somewhat. (p : S) => { p.x ← 0 } would have to be illegal, for example, though (p : S) => { (p.x, p.y) ← (3, 4) } might be permitted.

These are called refinement types (https://en.wikipedia.org/wiki/Refinement_type).

Provable termination isn’t strictly necessary I think, because compile-time evaluation, or metaprogramming in general, is usually Turing-complete anyway.

Haskell uses where in the sense the article describes.

E.g

   f x = y + 1
     where y = 2 * x

Haskell also has a "let" notation

    f x = let y = 2 * x
      in y + 1

> If a programming language wanted to use a keyword for restrictions that isn’t “where” (and still is a single word, hence “such that” doesn’t qualify), what word would be suitable instead? “With”? “Having”?

If? Python does so with it's list comprehensions:

  [ x for x in range(100) if x % 2 == 0 ]

"Given"?

I don't know SQL, but going solely off Google Images, that'd read like:

SELECT X GIVEN X > 5

Very nice. I wish people put this kind of careful thought in academic manuscripts.

The whole point of introducing a math equation in a paper is to serve as a completely unambiguous formalism, devoid of the ambiguities of the spoken word.

And yet, it is all too common to read something many times and not make sense of it, until it hits me the author means something completely different than what the symbols would imply in principle, and what looked like a formalism is basically a sloppy direct translation of words as math symbols, combined with abuse of notation, idiomatic but undefined uses of established notation, or outright nonsense.

It's a process. There is little utility to be gained from specifying mathematics, the title and abstract should explain why a general audience might care, but the meat is often for your advisor. If you think that more people will care then expand it out, use your school standards, even more? sure you can check out some knuth books on mathematical writing or use this grammar, but have you considered programming? It's by far the most inclusive and effective way to tell other people what you actually mean. Maybe popular languages aren't optimal for this try a specification language.

I'm in no way saying you should DO mathematics in a programming language, rather translate it for a wider audience. At a sufficiently high level even little kids could understand your argument before drilling down into specifics, and since the spec never actually has to run it can be as high level as you want limited only by verification time

Reply on news.ycombinator.com