Hacker News Reader

Comment by corndoge | Hacker News Reader

I am a mathematics student working as a systems software engineer. I find mathematical notation excessively dense and tedious to interpret.

Given the expression:

{f ∈ [1..N ⟶ 1..N] : ∀ y ∈ 1..N : ∃ x ∈ 1..N : f[x]=y}

I can instantly read it in my head as:

The set of all f where f is a function mapping 1..N to 1..N such that for all Y in 1..N there exists an X in 1..N such that f[x] = y.

One might argue that the ability to express such a long definition in such a compact form is a benefit, but I don't think so. In this particular case the definition is so trivial that it's easy to understand what is being talked about. Anything more complicated than this quickly becomes tedious and boring. I would prefer that mathematicians simply used longer, more verbose, but more clear and explanatory names for quantities and concepts. Just my opinion, though.

View on HN

I studied math and computer science at university. My personal experience was that if you wrote a long string with quantifiers in your vector spaces or analysis homework or whatever, the professor would ask you why you were acting like you were still in your 'Intro to Proofs and Logic' course and to please rewrite your homework in English. It was assumed that you could translate between quantifier predicate stuff and English, and that you should just therefore stick to English so your professor can actually read it. The CS faculty members were much more fond of writing stuff out in such formal terms like that (especially in the CS-oriented math classes like a general discrete math course, or an automata course) possibly because they thought the CS kids needed more practice with the notation.

My math profs emphasized juggling multiple layers of logical abstraction and omitting all unneeded explanations, while the CS guys wanted everything in excruciating detail and extremely formal language.

I graduated in 1989 with a math degree. For 24 years I didn't look at mathematical notation. Now in grad school for CS I'm seeing a lot of notation like you wrote. Some of it is coming back. But, it has become exceedingly difficult to remember a single Greek letter, embodying a concept, a page or so after it has been defined. The concepts are not especially difficult, but remembering symbols has become frustratingly so.

My current course is Programming Language Semantics. It's all relations, functions, states, predicates, induction, etc. Greek letters are used all over the place. The topic is interesting and I love implementing semantics in Prolog, but the mathematical notation is painful.

What's so hard about Greek letters? There's only 24 of them.

The problem is they are used as shorthand for complex ideas that the student is assumed to already know and be aware of. And don't forget upper and lowercase refer to different ideas, and if you are a physicist they will means entirely different things.

If mathematicians used longer notation then "the obscure symbol defined 5 pages back that I totally would remember if it was spelled out" would be more like 30 pages back. Brevity and standard notation are critical for understanding.

> Brevity and standard notation are critical for understanding.

Totally! That's why Perl has taken over the field of software engineering, vanquishing all who came before it.

And for the handful of people who find Perl hard to read and understand: choose another career because brevity and standard notation are critical for understanding, and Perl has that in more abundance than any other language. The problem, as it were, is you.

There's nothing standard about perl (parameter passing via lists, DIY OO, references in a scripting language, and there has to be more that I don't remember anymore - IMO these are the true reasons perl lost its popularity while ruby and python remain lively), nor is perl compact compared to other scripting languages. The parameter passing stuff especially made perl a verbose language.

> IMO these are the true reasons perl lost its popularity while ruby and python remain lively

As a perl cum python developer, no. It's that I had to spend time reverse engineering the code I wrote last week, because of the hundreds of obscure symbols I cleverly used to reduce thirty lines of clear code to five lines of compact code.

Python and Ruby both have to deal with references (though much more indirectly via the concept of mutable objects), as well as arguments coming in as parameter lists (and dicts).

So what in perl made it conductive to that kind of coding? I never worked with perl much but back then I got the impression perl being line-nose or whatever was more legend than reality. Perl's not a different paradigm like APL.

And by references I meant exactly that perl is not pass by reference, unlike just about any other scripting language. R is the only other popular one I can think of that's not. There's shell too but it doesn't count.

Python's not pass-by-reference either!

> So what in perl made it conductive to that kind of coding?

"Because I could"

More specifically, in very short programs, the shortcut values were actually valuable, and the mental overhead for interpreting them in short subroutines or programs was minimal. The problem is that programs don't stay static, and that single time-saving shortcut becomes two, then four, then eight, then...

Soon, it's an absolute mess.

Even once I realized the cost, I had to follow the coding conventions of those who had come before, at the cost of increasing the cognitive overhead even further. A self-reinforcing loop.

> not pass by reference, unlike just about any other scripting language

As Smaug says, Python is pass by value. The trick is that the value is always a reference to an object, or more specifically “pass-by-object-reference” (“Object references are passed by value.").

This causes a few subtle behavioral inconsistencies, such as the dreaded `def a(b=[]):` bug.

I'm way late to reply, but I never really understood what would qualify as pass by reference according to that logic :D you do have to pass a value eventually, it can't be references all the way

Verbose identifiers in program code are most useful near the top level, where the ideas they give a name to are very specific, while mathematical formulae often concern generalities, so verbose names are not always applicable (or at least not always helpful - even in code, identifiers that try to be too descriptive can make it hard to read, though people rarely err in this direction.)

One of the uses of the notation is to serve as a map for a more long-winded description, as you can lose your place in verbose explanations when they begin to get complicated.

More importantly, perhaps, is their use when you are applying formal manipulations to them. I think author's point is that many computer scientists apparently lack the background to follow or evaluate some of the important current developments in their field.

The notation and its meaning are both pretty clear, but I don't see how it converts to "the set of all permutations from 1 to N". And permutations of what? The integers 1 to N?

I guess that's why he talks about applications and not functions, so that guarantees there is a single x for each y.

I think he was just clarifying a point about the notation.

Given that each f is a function, mapping each member of its domain to one member of its range, and that for each member of the range, there is a member of the domain that the given function maps to it, and that the domain and range are the same size, then there can be no member of the domain not mapped to some member of the range, and each member of the domain must be mapped to a distinct member of the range (or else there would not be enough members of the domain to cover all the members of the range), so, with the domain and range being the same set, each of the given functions is a permutation of the domain, and collectively they must be all of them.

This is a verbose version of the argument for this being the set the author says it is. Arguably, it would be easier to read if I had used x for 'member of the domain', y for 'member of the range' and f for 'the given function'.

Permutations of the integers 1 to N, yes.

You can look at each permutation as a (unique, one-to-one and onto) function from the set [1,2,3,...N] to positions labeled also [1,2,3,...N]. For it to be a permutation, each position needs to contain a single value, and each value needs to be at one single location. Since the domain and range of the function have the same (finite) number of elements, either of these properties implies the other.

F(x)=y, s.t. x,y in [1,N]

There are so many ways to write the same idea in less symbols.

What you wrote is very ambiguous

I don't really know what you just wrote, but it's not "F is a surjection", which is what the post is capturing. If you're not quantifying somehow, even implicitly, then you're just not giving the same definition.

It can be written with fewer symbols: `f: [N]->[N] s.t. x != y => f(x) != f(y)` is an equivalent formulation, for instance (since f from a finite set to itself is surjective iff it is bijective iff it is injective). The quantification is now implicit in the "implies" symbol. Not sure how standard `[n]` is to refer to {1,2,…,n}; it was used commonly in my undergrad courses.

Reply on news.ycombinator.com