▲ 160 points
back
110 comments
By the way, write your plus sign (+) and lower-case letter Tee (t) so that they don't look identical!
From my experience, I'm one of the very few people who write manually in a serifed font; in particular, I write 1, l, I, and | very distinctly and use a slashed zero so as to distinguish it from the letter O. I wish more people would do this since it is still sometimes necessary to communicate on paper, and trying to interpret handwritten notes with ambiguous writing can be quite annoying.
Unquestioning faith in calculators.
The same can be said for computers too - except the problem is often worse as computers are far more complex to the point that almost no one understands them fully, and we are encouraged to accept this.
I write 1, l, I, and | very distinctly and use a slashed zero so as to distinguish it from the letter O.
My handwriting really similar. I use the cursive "l" in equations. Also I'm using Mathematica's i simbol for the imaginary unit [1] since teachers often forget about this and start using "i" for indexing sums too. It's quite common they appear in the same exponent.
I use a similar style of writing, including slashed 7s. I wish I could find a nice monospaced font with slashed 7s and 0s, etc.
Last time I saw a font with a slashed 7 and 0 was on Genera for the Lisp Machine. See it here: http://www.eurogaran.com/downloads/lispmfont/screenshot.jpg
> slashed zero
I'd also consider a dotted zero, or a reverse-slashed zero. That way it can't be confused with a null-set symbol (or phi, or a Danish vowel.)
I do the same, but only when I write mathematics. I have different i, j, k, l, q, t, x, and y. However, I always serif my 1's, and slash 7 and 0.
On the topic of handwriting, I remember this link[1] circling around during my senior year of high school. I pretty much took all of the advice.
Don't forget the slashed z so it's different from 2.
I studied undergraduate mathematics, and I think it's a field which requires the student to spend as much of their own time as needed to understand a concept. Perhaps this could be said of all fields, but there is just limited time in a class to absorb, e.g. Euler's Formula, because there are several concepts in play, and if the student doesn't have a firm grasp or recollection of one of them, then they get lost at one step on the chalk board, and the rest of the derivation is useless to them. This happened to me many times, and I'd just have to make a note to go figure something out, and the rest of the class was basically useless to me. Once it became more acceptable to have a laptop in class, I could just just look it up right then, and not have to wait till later, but I still just tuned out the professor.
Perhaps this could be said of all fields, but there is just limited time in a class to absorb
Which brings us to that what can you expect to actually learn in a class anyway?
I'd say that for any non-trivial curriculum (which ought to include most of a university...) you need to read about the subject yourself and do your own learning. And once you do that where do you need the classroom? For asking questions, maybe? But a classroom probably isn't the most effective way to ask questions.
This is why I really like learning math through MOOCS (with pause/rewindable videos) despite them having a number of other drawbacks.
When I teach calculus I give an hour-long-talk version of this document. I particularly emphasize that infinity is not a (real) number, so any arithmetic I see them doing with infinity will be automatically wrong; and that "equals" will be overloaded, and that most professors/TAs/tutors will not point out that there are different kinds of equals signs.
The stream-of-consciousness notation section also rang true. It's a huge frustration and time waster for everyone involved.
I particularly emphasize that infinity is not a (real) number, so any arithmetic I see them doing with infinity will be automatically wrong
I agree with you for the purposes of teaching undergraduate beginning level courses that involve mostly the real number system (and only incidentally the complex number system). That said, our learned fellow participant impendia here on HN, a professor of mathematics, has strenuously disagreed with me by pointing out the specialized number systems that do treat infinity somewhat like a number. On my part, for the students I encounter, I stick to discussions like "All about Infinity"[1] (formerly titled "Infinity Is Not a Number - It's a Free Man") Katherine Körner, another astute mathematician. I have frequently seen discussions of infinity as a (real) number here on HN that essentially boil down to the error of treating the quotient upon dividing by zero as a real number.
My god, if someone created a similar list for undergraduate Computer Science education, I would be astoundingly happy.
Shouldn't be too difficult. I haven't done much teaching and could write a short list. Unfortunately, I don't think it would be very surprising to most people (just as this list probably isn't surprising to most math majors, since we've all made at least one of these "stupid mistakes" before, even when we knew better, especially in the early years. The difference -- and this is reiterated several times -- is that good/smart students notice their error and debug their math/program, instead of just going with it or fudging their result).
Here are a few:
* Not actually thinking of a solution to the problem before starting to write a program; not soliciting requirements.
* ALL of the mistakes covered by this article. Struggling CS majors are often (not always) really, really horrible at math, and this -- more than anything else -- really holds them back from writing correct programs.
* Off-by-one and the functional equivalents
* Infinite loops in exception handling
* not enough input validation; too much input validation
* Reinventing bad versions of existing algorithms (Dijkstra's algorithm is a good example) and in general not enough research before implementation.
* The other side of that coin is taking stack overflow upvoted answers as gospel (basically our equivalent of trusting the calculator)
* Fundamental incomprehension of boolean algebra, which gives rise to all sorts of errors:
incorrect paren placement
Obscenely complicated conditions and/or absurd if conditions because they don't understand boolean algebra (e.g. I've seen conditions that eventually simplify to a || !a)
Complicated programs and grandois bug-hunting because they couldn't figure how a simple boolean expression (there was a post on HN a while back about Javascript == vs === where the developer basically wasted a day going down a rabbit hole he attributed to == vs === but was actually completely avoidable if he had taken an undergraduate discrete math course that hammered home boolean algebra.)
* This page contains a very useful implementation details section which describes some common errors implementing quicksort: http://algs4.cs.princeton.edu/23quicksort/
* As a general rule, any program written by a student containing concurrency is always wrong, unless concurrency was explicitly taught (many schools just have a short unit in a course or two, instead of integrating the topic throughout the curriculum).
Here's a less extensive article I read a while ago: http://fob.po8.org/student-code
One realises how confusing and complicated are the standard notations when one implements a programming language. You would prefer Lisp/Scheme or RPN notations, but they both scare away a lot of people, who prefer "natural" notations. People don't realise that they probably hurt them as much as they help them.
It seems tempting to have a single unambiguous notation for mathematics. But
In constructing such a language, one will quickly realize that doing mathematics becomes an intensely arduous task.
This is not unlike recent discussions about the conlang Ithkuil on HN.
For better or for worse, math notation has for the most part been optimized for writing on paper or a blackboard, using context to eliminate "inessential details". Local edits are generally easy, and pieces of notation are not always so tightly coupled. (For example, we can put a "for all x" at a distance from some equation.)
Have you ever attempted to write Lisp on a blackboard, then needing to insert an expression in the middle? It's extremely difficult because you have to perform a quadratic process (erasing everything after and reindenting) to make the Lisp readable. At least this is what I've noticed in interviews. You can sometimes patch your Lisp forms with lines and arrows, but it's the quickest way to get spaghetti on your blackboard.
RPN is similarly useless for the task. RPN is exceedingly easy to write, but not so easy to read. Also, higher level mathematics becomes unwieldy in RPN.
Sussman and Wisdom in their book "Structure and Interpretation of Classical Mechanics" did take a different approach to math notation in order to make it unambiguous for that relatively small sub field. It looks like regular math notation but written in such a way to make things more easily computable. I'd say they were successful, though their work would be difficult to generalize.
"An equation such as ∫ 3x^2 dx = x^3+C says that we add together uncountably many infinitesimals, and we get a medium-sized number."
Yelp! My buddies Riemann & Lebesgue had quite a different story on the matter...
Non-standard analysis (e.g. http://www.sjsu.edu/faculty/watkins/infincalc.htm -- another example of awesome web page design) does formalise the concepts of infinitesimals. It's quite neat to have a complete alternate formalism for calculus.
I disagree that 0^0 is undefined. I would argue should be 1 and the function 0^x is not continuous at zero. The basic definition of exponentiation for integers is n^m is a product of m instances of n. Because the multiplicative identity is 1, a product of zero numbers is always 1. Therefore 0^0=1.
It goes deeper than that.
Many things in mathematics are defined in a manner that is consistent and convenient. Defining 0! to be 1 is a similar case. In doing so nothing goes wrong, and the binomial theorem becomes simple and convenient to state. Without defining 0! as 1, it's a dreadful mish-mash of special cases.
Similarly with 0^0. Considering x^y where x and y are complex numbers, there is no consistent single value as x and y each approach 0. So in the reals and the complex numbers we leave 0^0 as undefined. However, in the case of natural numbers there is a case for declaring 0^0 to be 1. That's to make it convenient to talk about the set A^B as the collection of functions from B to A. When we do that we get |A^B| = |A|^|B|.
There is more than expected in mathematics that's defined for convenience.
The debate goes beyond that point, as illustrated by the lengthy Wikipedia section:
https://en.wikipedia.org/wiki/0%5E0#Zero_to_the_power_of_zer...
From an undergraduate math point of view, it's wise to understand that 0^0 is not well defined.
It's more of an open question than your reply would seem to indicate:
http://mathforum.org/dr.math/faq/faq.0.to.0.power.html
It's less controversial when the terms are integers, but even there an argument can be made for indeterminacy. As the linked article says, "There is no one definition that always works well for 0^0"
I can use 0^0 = 1 to prove that 1 = 2, but I'm sure you can anticipate the argument's form.
The main argument that it shouldn't be defined because there will be some situations where any definition will fall short.
Your definition only works for situations where you are dealing with integers.
I posted an article about 0^0 to HN sometime back: http://www.askamathematician.com/2010/12/q-what-does-00-zero...
HN discussion: https://news.ycombinator.com/item?id=7519827
The limit of x^x does equal one when approached from the right (i.e., when x is positive, reducing to zero). From the left, it also approaches one, but is only continuous over the complex numbers. Anyway, while the limit approaches one from both sides, the function cannot be evaluated at x=0 and so is undefined.
I've seen many instances of the "undistributed cancellation" error, most commonly in even simpler cases than the one in the article:
Given a fraction similar to:
x + y
-----
x
Yes, but if we cancel the 6's in 64 / 16, we get 4/1 or 4. :P
Oh, and incidentally, sin(x) / n == 6.
I just realized I have forgotten how to add fractions! I don't think i've ever had to do this in the day job. I've been out of school for 10 years.
Mostly off-topic, but I found the Altavista linkback search link on the top of the page really... something. "Cute" would be the wrong word, but it comes closest to describing what I felt.
http://www.altavista.com/cgi-bin/query?q=link%3Amath.vanderb...
Goes very well with the vanilla html typography too. archived https://archive.today/6fzmw
"As we've used all the letters of the Roman alphabet, and the Greek one too, I'm just going to write these letters really bold; take notes carefully, there are no distributed notes nor textbook for this freshman analysis course."
I had a calc prof who spent most of a class lecturing on "RTFT," where the last T was Text Book instead of M for Manual because he thought somebody asked a stupid question.
To be fair, the question was kind of dumb. But the textbook was also worthless and created to generate revenue for the math department. So it's unlikely his proposed solution would have helped the student in question.
Not to mention that the lecture on RTFM didn't help anyone learn math anyway.
The student who asked the question probably never really understood the math (wrote learner), but did become the prof's office hour best friend and got a good grade anyway.
Anyway, file under the teacher hostility section of this article, I guess.
One of the most bizarre errors I've seen undergraduates make is in induction proofs. I saw it so many times that I decided a TA must have been telling them to do this.
They would always show the base case correctly. Then they assume it's true for all positive integers up to a fixed positive integer "n." So far so good, now we need to prove it's true for "n+1." This is where weirdness happens, I have seen a hundred assignments where an equation is reduced down to "0=0" or "1=1" and they then write "Q.E.D" even though the fact that 0=0 was not under contest.
All horses are of the same color.
By induction, suppose there are only n=1 horses. Obviously they are all the same color.
Suppose we had proven the statement up to n. For every n+1 horses, the first n horses must be the same color. The last n horses too, must have the same color. Clearly all of them have the same color. QED.
I'd guess it's probably because they don't actually understand proofs in the first place. There are a lot of computer science undergrads who go in with math only up through calculus somewhere and get totally lost when it gets to this weird wibbly-wobbly place where you have to make logical statements using previously unknown Latin notation instead of just solving for x.
Wait, I am missing something here. If the reduction to a true statement is done through operations that can be performed in both direction (which are most of the trivial operations undergrads use) then this is a perfectly fine approach, right?
I'm surprised that the author made no mention about how big O,theta,and omega is commonly misunderstood.
I studied mathematics as an undergraduate and found that these topics aren't covered in pure math classes typically until students are sufficiently experienced that they can grasp the fully technical definitions.
It's more common for CS courses rather than math courses to rush the definition of Big O out the door to students who will struggle to understand the formal definition.
Likely because the author is a math professor and those concepts are typically only covered in CS department courses.
You know, this post may cause problems though.
There is something called photographic memory...
Aka most common undergraduates who study math do not know math.
First of all, your statement is meaningless. What exactly does it mean to "know math"?
Here's an alternative explanation: math students do lots of computations, and sometimes make mistakes which they would be able to identify immediately if someone told them "you made a mistake on this line".
Kind of like how all programmers occasionally drop a paren or a semicolon. Does that mean no programmers "know programming"? Of course not.
In fact, if you've never made a stupid mistake programming, odds are you're not a very good programmer because otherwise, you'd have done enough programming that one of these mistakes became inevitable.
The only difference is that most programming is simpler than university-level mathematics, so with a few decades of research we figured out how to use computers to prevent us from making a lot of mistakes without impeding our productivity too much.
For example, from the article:
"In fact, the great mathematician Leonhard Euler published a computation similar to this in a book in 1770, when the theory of complex numbers was still young."
So another way of wording your post: Euler doesn't know math.
Similarly, many of the examples (e.g. calculators) could be interpreted as students knowing too much math, and excepting their tools or others to know the same "math" they know.
Do yourself a favor and shrink the browser width to about inches.
And learn about why newspapers are laid out in columns.
> are laid out in columns.
Because they can't be resized on the fly?