[xg15]

Fully agreed, though to nitpick:

> Rather than precisely say, f(2) = 7, we say that for x=2, f(x) = 7. So x is simultaneously an indeterminate input and a concrete value

This seems like a perfectly by-the-book piece of second-order logic with two equality predicates.

i.e., the statement asserts that if you look at the space of all possible values for x, then for each value where the predicate "x = 2" holds, the other predicate "f(x) = 7" will also hold. It happens there is only a single value that will satisfy "x = 2", but that's not the equality's problem.

So both = signs really are equality here.

[j2kun]

Fair point. I'd add that f(x) = 7 can be both equality of functions and equality of evaluations, and binding x=2 suddenly changes the meaning of the equality and the expression.

[OscarCunningham]

I think "f(x) = 7" is always equality of the evaluations, and if you want equality of the functions you should write "forall x, f(x) = 7". Admittedly mathematicians are lazy and don't always write that when it's clear from contex, but I don't think the ambiguity is caused by the "=" sign. The expression "f(x) < 7" would be equally (ha) ambiguous.

[xg15]

True. I don't want to dispute that there is a hell of ambiguity in using =.

[diffeomorphism]

I wouldn't call that ambiguity. While several shorthand notations use =, it is always clear from the context which one and only one is referring to (and if there are multiple that all of them agree).

This touches on another point that one sees much of in mathematics lectures but little in math lectures. Mathematical notation needs to be unambiguous but also facilitate communication and hence tends to be very terse. Thus when discussing addition on a finite field F_5, one usually starts defining equivalence classes [j] and an addition operator "+" and then says that [3]"+"[3]=[3+3]=[5+1]=[1] followed by a disclaimer like:

"We hence see that this notion is compatible with the previously defined one when identifying ... . Hence, if there is no possible confusion, we will simply write ..."

See also Tao's comments on rigor in mathematics: https://terrytao.wordpress.com/career-advice/theres-more-to-...

All notation can be made rigorous, if one wants to, but discussion is more concise if we let everybody do that by themselves.

[xg15]

Yeah, I think that's a good point and, I think, an important differecne between math notation and programming languages.

I think mathematicians thend to use a lot of "notational slang" or "ad-hoc syntactic sugar", if you will. This will make the notation often look imcomprehensible for people not familiar with the exact domain - however, there is usually a consistent meaning behind it. If one wanted, the notation could be "desugared" into a more rigid (but more verbose) form that expresses the same.

To take big-O-notation as an example, if you write something crazy-looking like

  x + 5 = O(x)

What you mean is

The function "f(x) := x + 5" is a member of the set of functions "O(x)".

Where "O(x)" is itself shorthand for a convoluted set expression.

Similarly, if you write

  x^3 + O(x)

You mean Take x cubed, then add the result of some function from the set O(x). (Whether you mean any function or one specific function is again context-dependent but usually it's made clear which of the two is meant.)

Contrast that with programming languages, where you often have a rigid syntax but higher-level semantics being quite fuzzy.

E.g., equals() and toString() in java are straight-forward to write but they can "mean" quite a lot of different things depending which kinds of objects you call them.

e.g., the "obvious" meaning of equals (value equality) works only with immutable value types - yet the method is defined on any kind of object. So it might also mean instance equality - or even entity equality if you deal with ORM proxies - or even wilder things...