[osoba]

U, V: vector spaces

u, v: elements of vector spaces

G, H: groups

g, h: elements of groups or

g, h: homomorphisms, isomorphisms etc

e: group identity

K, F: fields

I: ideals

f: functions

(x): sequences

x_i: i-th element of a sequence

A, B: matrices

It all depends on the context it's used of course

[danielpatrick]

This notation has developed over tens to hundreds of years before we had the capabilities of autocomplete and formal typing where a computer can help us write longer names more quickly. This is why single letters became prominent, they were simply easier and faster to write.

But anyone who is serious about writing maintainable code today should be using an IDE where the benefits of susinctness are entirely relegated by intellisense-like tools.

Trading readability for conciseness is near the top of my list of "crimes against future maintainers."

So I had never thought about this in the context of mathematical symbols, but this makes total sense and I'm strongly in favor of relegating mathematical conciseness in favor of readability and specificity.

[osoba]

It's actually the other way around. Mathematical notation used to be very much language-like and tedious to read. As time went by (and math became more complicated) notation was developed to make it more succinct and easier to understand. (And sometimes the more succinct notation helps to develop new insights. The change from Roman to the Indian/Arabic number systems made calculations easier for everybody) https://en.wikipedia.org/wiki/History_of_mathematical_notati...

Compare the two following statements:

One from Euklid's elements (written 2.5k years ago):

"Given two straight lines constructed from the ends of a straight line and meeting in a point, there cannot be constructed from the ends of the same straight line, and on the same side of it, two other straight lines meeting in another point and equal to the former two respectively, namely each equal to that from the same end."

And my attempt of translating the above, in what should effectively be Hilbert's notation (19th-20th century):

If there are two triangles ABC and ABD where AC=AD and BC=BD and C and D are on the same side of AB then C and D are the same point.

Which one was easier to parse in your mind?

As a bonus try rewriting this formula using longer variable names and tell me how legible it would look http://i.imgur.com/wCWkyNL.png (it's from a proof of one of Syllow's theorems https://en.wikipedia.org/wiki/Sylow_theorems )

[douche]

Conversely, you just draw a picture and leave all of this tedium behind, making the import of what you are talking about obvious at a glance.

[osoba]

Proofs by picture arent proofs though. And how would you even convey by picture that two line segments are of the same length. Or that if you drew C and D as separate points they turn out to be the same point?

[qznc]

Oliver Byrne's edition of Euclid is a nice proof-by-picture example: https://www.math.ubc.ca/~cass/euclid/byrne.html

[osoba]

Those look more like proofs with pictures, than proofs by picture, but I'm too lazy to get involved into the obscure notation of that book and check whether a random proof from the book would be equivalent to a modern proof from a standard textbook.

Altough, judging by the old timey language of the book, it's possible the book predates Hilbert's axiomatization of Euclidean geometry and the proofs in it were good enough for the standards of its time.

In modern mathematics proof by picture generally means you've drawn / pointed out a single example, possibly wrongly or in a way that doesn't generalize, and because you've shown that one example holds you assume all possible examples hold. That, obviously, needs not be the case.

[gbrown]

If you're talking about mathematically rigorous programming, conciseness and readability go hand in hand. It's actually easier to read a formula with single letter components than a complex one with long descriptive names in many cases. Also, if you're doing that kind of programming, you're also doing a lot of hand or latex computation. Minimizing the visual distance between the code and the convenient handwritten or typeset notation is incredibly important.