This shouldn’t be “memorized” as a “fact” though. As you point out, it’s the very definition of e. Which is to say, to really understand what the exponential function means implies building up a mental model about lim [n→∞] (1 + x/n)^n and its behavior, interacting with it, connecting it to other functions, seeing what happens when you combine it with other ideas: trying to integrate/differentiate it; noticing how it reacts to fourier transform; relating it to rotations, areas, imaginary numbers; writing it as a taylor expansion or continued fraction, or with a functional equation, or as the solution to a differential equation. Connecting it to derived functions such as e.g. the normal distribution, or sine, or hyperbolic sine. Generalizing it to an operation on complex numbers, or quaternions, or matrices. Thinking about what exponentiation in general really means. Coming up with algorithms for computing e’s decimal expansion or proving that e is irrational and transcendental. Solving problems with it, like to start with, continuously compounded interest (&c. &c. &c.).
No one who had really learned about exponentials in a deep way would easily forget that this is the definition of e, and that has nothing to do with lists of facts or rote memorization.
> Single-character symbols (and multiple character symbols) that not only hide tons of meaning through a dereference, which is naturally how language works, that also suggest a meaning themselves, are stupid and promote natural diseased human thinking.
I think you should try writing out some very difficult complex math proofs before you make this assertion (say, for instance, a proof . Things are bad enough when we pack ideas down. Start expanding them in the middle of the computation, and it the steps become almost impossible to see or reason about.
The whole point of assigning things short simple names is that it gives a clear analogy (to past experience w/ the conventions) that provide a shortcut to anticipating how particular types of structures and operations behave. Cramming a matrix or a multivariate function or an operator down into a single symbol helps us to treat that symbol as a black box for the purpose of the proof or problem, which helps us bring our existing mathematical tools and understandings to bear. Sometimes, we run afoul of false impressions, as when we apply intuition about the real numbers to matrices in ways that don’t quite apply, or intuition about metric spaces to general topological spaces, &c. But this is I think an unavoidable cost, and it’s why we strive to be careful and precise in making mathematical arguments.
http://mdzlog.alcor.net/2010/07/12/read-listen-or-comprehend...
> What’s interesting is that the pattern varies from person to person. Feynman shared his discovery with a group of people, one of whom (John Tukey) had a curiously different experience: while counting steadily, he could easily speak aloud, but could not read. Through experimenting and comparing their experiences, it seemed to them that they were using different cognitive processes to accomplish the task of counting time. Feynman was “hearing” the numbers in his head, while Tukey was “seeing” the numbers go by.
So while pushing around abstract symbols might be the way that you really grok things, I don't think this applies to everyone. I have an undergrad math minor, and the only math class that I didn't get an A in and that I really struggled with was Linear Algebra.
I think it mostly had to due with excessive symbolic abstraction. Matrix notation still really troubles me. About 5 years after that Linear Algebra class that I struggled with, I was took a computer graphics class for a masters degree. We were talking about the non-invertibility of some operation (I think it was about figuring out how far something was away given a 2d rendering of a 3d scene, where you have a degree of freedom in the scale, everything could be twice as large and twice as far away). And that gave me a really intuitive understanding between matrix invertibility and full rank matrices. I am sure that I would have done much better in a combined Linear Algebra/Computer Graphics class than I did in just the mostly symbolic and proof based Linear Algebra class.
So be careful in believing that the thought processes that obviously work well for you will also work well for others.
I would suggest that someone who has trouble (serious trouble that is) with linear algebra might have also trouble with other abstract things in computer science, like automata theory or grammars and compilers.
public interface List<T> { ... }
Tree a = Empty | Branch a (Tree a) (Tree a)
This question at math.stackexchange.com goes into a little more detail: http://math.stackexchange.com/questions/24241/why-do-mathema...
Plus, the math tradition of one-character variable names means that they've had to adopt several different alphabets just to get enough identifier uniqueness (greek, hebrew, etc., plus specialized symbols like the real, natural, and integer number set symbols). Which makes all that stuff a pain to type. And even then, there are still identifier collisions where different sub-disciplines have different conventions for the meaning of a particular character.
It's also annoying because single-character names are impossible to google for.
t a = e | b a (t a) (t a)
Tree someData = Empty | Branch someData (Tree someData) (Tree someData)
One difference between programming and mathematics is that programming is mostly interpreted in context, when it matters that this double represents elapsed time, and this double represents dollars in my checking account. Mathematics, on the other hand, is mostly interpreted out of context. I don't care what a represents, all I care about is that it enjoys the relationship ab = ba with some other arbitrary object b.
If the mantra of programming is "names are important" then the mantra of mathematics might be "names aren't important".
So if you really don't care what a variable represents, then I'd agree that a single-letter name is fine. Given that math is almost universally done with single-letter variable names, are you suggesting that in math you almost never care what a variable represents? This wikipedia article makes me think otherwise; clearly, variables often have a fairly specific meaning.
http://en.wikipedia.org/wiki/Greek_letters_used_in_mathemati...
Thanks for the link, there are some good thoughts there.
The way most mathematicians ignore this problem is by throwing two variable names next to each other, so xy is x times y. Obviously, this system is incompatible with multiple-letter variable names. I have unfortunately seen the two concepts mixed, which makes reading an equation like reading ancient Greek or Latin (which lacked spaces and punctuation).
Until there is a commonly accepted, easily distinguishable symbol for multiplication, I don't see single-letter variables going anywhere, or multiple-letter variables being used in general mathematics.
We could obfuscate further by XML replacement parentheses: <sum> <term>1</term> <term> <quotient>...</quotient> </term> </sum> But the structure is more important, right?
Why is the command line powerful? Because it offers a large number of utilities that are highly configurable and that can be linked easily.
But you could have just the same expressiveness if the interface was eg. a circuit diagram, where you connect configurable commands with lines.
You know why the command line uses text input? Because it is the simplest to implement. The only people who need to know how to use the command line are people who need to use software where it doesn't pay off to make a more intuitive interface.
Lastly, the command line gets a good deal of power from meta-programming: most commands deal with a loosely structured stream of text, and a set of commands is a loosely structured stream of text. Specifically in POSIX environments, primitives like command-substitution ("$()" or backticks) and the xargs command are powerful ways to write commands that construct and execute other commands. If your diagram-based UI contains a set of primitives for launching commands and working with text, you're going to have to add a whole new set of primitives for working with diagrams.
I only skimmed this comment, I'm afraid.
While I sympathize with the opening, because many neat things have been made/discovered without the person having any formal math knowledge like what the "U"-looking symbol in an equation stands for:
>"The power to understand and predict the quantities of the world should not be restricted to those with a freakish knack for manipulating abstract symbols."
I heavily disagree with the conclusion:
>"They are unusable in the same way that the UNIX command line is unusable for the vast majority of people. There have been many proposals for how the general public can make more powerful use of computers, but nobody is suggesting we should teach everyone to use the command line. The good proposals are the opposite of that -- design better interfaces, more accessible applications, higher-level abstractions. Represent things visually and tangibly.
>And so it should be with math. Mathematics, as currently practiced, is a command line. We need a better interface."
I think the notion that they're unusable by the vast majority of people because of something fundamental about people is false. At some point in time reading and writing were not done by the vast majority of people, then they came into existence. Even as recent as 500 years ago, the vast majority of the population neither read nor wrote. Along came public education and that proportion flip flopped insanely fast such that the vast majority are capable of reading and writing (regardless of how good they are at it). Reading and writing were just as radical novelties as computing, just because something is a radical novelty doesn't mean most humans can't be proficient at it eventually.
I think we should teach everyone to use the command line. Well, not Windows' CMD.EXE, but bash preferably in a gnome-terminal. Here is a short quote expressing why I think this is a good idea:
>Linux supports the notion of a command line or a shell for the same reason that only children read books with only pictures in them. Language, be it English or something else, is the only tool flexible enough to accomplish a sufficiently broad range of tasks. -- Bill Garrett
I think we should teach everyone how to interact with the computer at the most general way--which means programming. Which means commanding the computer. Describing the inverse square law in terms of pictures and intuition isn't going to make it any more of a tool than some other method, people are still going to think of it as something one is taught. The only way to make it seem like a tool is to use it as a tool, this means programming for some purpose. Maybe a physics simulation. And the beauty of tools is why the software world has exploded with utility despite Dijkstra's depression at programmers' inability to program extremely well. The beauty of tools is that they can be used without understanding the tool, just what the tool is useful for.
The "Things Other People Have Said" at the end is more interesting than the essay.
I wonder what Dijkstra would think of it. My two best guesses are "This is just a continuation of infantizing everything" and "We did kill math, with programming." I think a lot of people's difficulties with symbolic manipulation are due to the symbols not having immediately interpreted meaning. Dijkstra seems to recommend fixing this by drilling symbol manipulation of the predicate calculus with uninterpreted symbols like "black" and "white". My own approach I have been using more and more is to just use longer variable names in my math, whether written or typed. It really seems like this simple step can be a tremendous aid in understanding what's going on.
Over the past couple of years I've realized just how important sheer memorization can be as I see almost everyone around me struggle with basic calculus facts, which means they struggle with application of the facts. The latest example from a few weeks ago in a junior level stats course with calc 2 prerequisite (which many people take 2 or 3 times here apparently) was when apparently no one but me recognized (or bothered to speak up after 20 seconds) that (1+1/x)^x limited to infinity is the definition of e, which we then immediately used with (1 - const/x)^x = e^(-const). (Which is immediately related to the continual compound interest formula that changes (1+r/n)^nt to e^rt as n->infty which everyone should have seen multiple times in algebra 2 / pre calc when learning about logarithms! The two most common examples are money and radioactive decay.)
Sure that's a memorized fact for me, it's not necessarily intuitive apart from the 1/x being related to logs which are related to e, but come on. In my calc 3 course that I didn't get to waive out of, where it was just me and two others, I was the only one who passed, and when the teacher would try to make the class more interactive by asking us to complete-the-step instead of just a pure lecture the other two were seemingly incapable at remembering even the most basic derivative/integral pairs like D[sin(x)]=cos(x). A lot of 'education' is students cramming for and regurgitating on a test where the teacher hopes (often in vain) that the cramming resulted in long-term memorization. I do this too, cram and forget, but maybe I just do it less frequently or for less important subjects or my brain's wired to memorize things more easily than average (but I disfavor hypotheses that suppose unexplained gaps in human ability as largely static). My high school teacher's pre-calc and calc courses had frequent pure memorization tests such that there wasn't a need to cram elsewhere because that iterative cramming was enough to get long-term memorization (with cache warmups every so often; I did have to breeze through a calculus book in preparation for a waiver exam last year).
A person can only hold so many things in their active, conscious memory at once (some people think it's only 7 plus or minus 3 but that seems like too weird a definition of 'thing' that results in so little; human brains are not CPUs with only registers r0 to r6), so when you start looking at a math proof with x's and y's and r's and greek letters and other uninterpreted single-character symbols all over the place, it's incredibly easy to get lost. If you start in the middle, if your brain hasn't memorized that "x means this, y means this" for any value of "this", you have to do a conscious lookup and dereference the symbol to some meaning even if the actual math itself is clear. My control systems book uses C and R for output/input (I already forgot which is which) but it's so embedded in my brain that Y is typically output and X is input that I use those instead, as does the teacher. I agree with Dijkstra that practice at manipulating uninterpreted symbols makes it a bit easier, but there are quickly diminishing returns and ever since I started programming and saw how PHP uses the $var syntax to denote variables I've been thinking "Why hasn't this caught on in math? It makes so many things much clearer!" But it's not so much the "$" in $var (or @var and other sigils in Perl) but the "var". Saving your brain a dereference step is pretty useful.
Single-character symbols (and multiple character symbols) that not only hide tons of meaning through a dereference, which is naturally how language works, that also suggest a meaning themselves, are stupid and promote natural diseased human thinking. My poster-child here is global warming. Every winter you'll hear the same comments on "When's global warming going to hit here?" The poor choice of global warming as a variable that points to a bigger theory has cost it heavily in PR because humans look at only the phrase instead of what it points to, it's still so bad that people's every day experiences, which they use to form a subconscious prior probability in global warming as a theory, contain "it's really hot all the time and everywhere I've been!" and so they look at "global warming" and dismiss any evidence for/against it based purely on the name and how their experience seems to contradict the name. It's like a computer thinking that a pointer address that happens to correspond to 0xADD means it should invoke addition when it should figure out what 0xADD points to instead which could be anything.
Another use of long names is with Bayes' Theorem in probability. It is only through memorization of the uninterpreted symbols A,B,C themselves that I remember prob(A | B, C) = prob(A | C) * prob(B | A, C) / prob(B | C) But it never made intuitive sense to me and I never bothered memorizing until it was expressed as prob(hypothesis | data, bg_info) = prob(hypothesis | bg_info) * prob(data | hypothesis, bg_info) / prob(data | bg_info). (Sometimes data is replaced by model.) The notion that it relates reason with reality, that it encapsulates the process of learning and scientific reasoning, elevates the equation to the status of a tool instead of something you cram for and regurgitate on a test. An immediately useful application for the tool is using Naive Bayes to filter spam.