11–20 of 206 posts
=
eq
eql
equal
equalp
string=
...
Oh, and the wonderful notation for integrals, ∫ 2x dx = x² + C
A succinct summary is that mathematics is about understanding a thing and computing is about describing a concrete process.
> 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.
Operators in mathematics are overloaded in a very similar way to operators in computer science (in languages that permit overloading). I think the author hints toward a good point: there is no use arguing over the meaning of "=" in a general sense, because the meaning is contextual. I think this whole discussion is merely indicative of inexperience on the part of computer scientists attempting to navigate mathematics…
Lisp has many flavors of "equal": = eq eql equal equalp string= ... Because equivalence mean many things in both the mathematical and programming world.
Operators in mathematics are overloaded in a very similar way to operators in computer science (in languages that permit overloading). I think the author hints toward a good point: there is no use arguing over the meaning of "=" in a general sense, because the meaning is contextual. I think this whole discussion is merely indicative of inexperience on the part of computer scientists attempting to navigate mathematics…
CS already abuses equality all the time with big-O notation. Often you see stuff like f(n) = O(N²), when they mean that f ∈ O(N²). It's fine because everyone knows what's going on, but it's not using it in the sense of equality.
For instance we might say:
sin(x) = x -x^3/6 + x^5/120 + O(x^7)
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…
> If mutation is so great, why do mathematicians use recursion so much? Huh? Huh?
> Well, I’ve got two counterpoints. The first is that the goal here is to reason about the sequence, not to describe it in a way that can be efficiently carried out by a computer.
Most high level languages try to avoid making the programmer describe the most efficient way to handle variables. The idea is to describe your algorithms and how they connect and allow the compiler (or interpreter) to figure out how to use registers etc to implement it. Of course that ideal breaks down sometimes but most high level programmers don't normally need to stress the low level details too much.
> My second point is that mathematical notation is so flexible and adaptable that it doesn’t need mutation the same way programming languages need it. In mathematics we have no stack overflows, no register limits or page swaps, no limitations on variable names or memory allocation, our brains do the continuation passing for us, and we can rewrite history ad hoc and pile on abstractions as needed to achieve a particular goal.
It's true that there's a limit to abstractions even the highest level languages can make if they want to remain general purpose. However I think languages can handle immutable variables as a default.
That's not to say I agree that programming should always follow mathematical notation. But I also don't think it's a bad ideal in many cases.
S[ x ↦ V ]
indicates that the new state is equal to old state S, but with variable x now bound to value V.