16 4 / 2012
It's not too hard
There is no similarly mechanical procedure that can be easily taught to a high school student in order to solve such a problem “mindlessly”
05 2 / 2012
Introducing new topics
It already starts with the teaching of arithmetic. Instead of teaching 2 + 3 = 5 , the hideous arithmetic operator “plus” is carefully disguised by calling it “and”, and the little kids are given lots of familiar examples first, with clearly visible such as apples and pears, which are in, in contrast to equally countable objects such as percentages and electrons, which are out. […] The educational dogma seems to be that everything is fine as long as the student does not notice that he is learning something really new; more often than not, the student’s impression is indeed correct.
(Emphasis mine)
It’s hard to say whether this is a problem, or a solution. I think we’re not introducing these topics (such as calculus) early enough, and therefore when they are introduced, say during your senior year, they seem almost scary. We’re giving students an impression that these topics are super hard, when in fact something like a limit is a fairly simple concept.
So is the problem that we’re trying to relate it to something we already know, or that we’re building it up to be more difficult than it is? I might argue both.
Some more interesting quotes from this link:
If we push a little harder we expect to do a little better. Very often the behaviour is not only a continuous but even a monotonic function: to test whether a hammer suits us over a certain range of nails, we try it out on the smallest and largest nails of the range, and if the outcomes of those two experiments are positive, we are perfectly willing to believe that the hammer will suit us for all nails in between.
It is possible, and even tempting, to view a program as an abstract mechanism, as a device of some sort. To do so, however, is highly dangerous: the analogy is too shallow because a program is, as a mechanism, totally different from all the familiar analogue devices we grew up with.
In what we denote as “primitive societies”, the superstition that knowing someone’s true name gives you magic power over him is not unusual. We are hardly less primitive: why do we persist here in answering the telephone with the most unhelpful “hello” instead of our name?
Unfathomed misunderstanding is further revealed by the term “software maintenance”, as a result of which many people continue to believe that programs —and even programming languages themselves— are subject to wear and tear. Your car needs maintenance too, doesn’t it? Famous is the story of the oil company that believed that its PASCAL programs did not last as long as its FORTRAN programs “because PASCAL was not maintained”.
When all is said and done, the only thing computers can do for us is to manipulate symbols and produce results of such manipulations.
After all, it is no longer the purpose of programs to instruct our machines; these days, it is the purpose of machines to execute our programs.
Computing science is —and will always be— concerned with the interplay between mechanized and human symbol manipulation, usually referred to as “computing” and “programming” respectively.
No endeavour is respectable these days without a TLA (= Three-Letter Acronym), I propose that we adopt for computing science FMI (= Formal Methods Initiative), and, to be on the safe side, we had better follow the shining examples of our leaders and make a Trade Mark of it.
06 9 / 2011
Taking abstraction too far
A friend of mine loves abstraction. He’s been coding more and more with this in mind. Normally this is good, it allows for a cleaner implementation with more options for developers. I think he’s taking it too far.
He wrote an expression parser. Give it a string of maybe “sin(5) + 4 * 3” and it’ll use order of operations and evaluate correctly. Give it a string like “sin(y*(pi/180 ))” and a variable for “y” and it’ll evaluate as expected.
But when it came time to implement “pi” he was stubborn at first. He argued it should be supplied as a variable just like “y” and “x”. Of course I can see his reasoning, however as a developer who would consider using this library, it was illogical. The string “pi” should always be the constant M_PI, and making someone else supply this for every calculation seems like a waste. Sure, you could argue “What if they wanted to use that variable name?”. My thought: they shouldn’t use that variable name.
PI is PI, just like 5 is 5 and 11 is 11.
He’s not the only one with this problem. Sometimes I’ve stopped working on a project for days trying to sort it out in my head - trying to figure out the cleanest way to code something. But during that time I’ve learned I have to just build shit and when it breaks, figure it out then. I’ve been spending too much time worrying about how to do it right and in the end I haven’t done it at all.
25 7 / 2011
Python adventures
Throughout my geeky math adventures I have began to learn the programming language of Python. Coming from a PHP, Javascript and C background, the transition was relatively easy.
I’d like to share a very simple function definition with you. All it does is tell you if a number is a perfect square (e.g. 4, 9, 16, 25, 36) or not. It uses existing methods. But it’s the fastest method I’ve found so far. I can compute 50,000,000 numbers in under 50 seconds on my Macbook.
from math import sqrt
def is_perfect_square(n):
return sqrt(n).is_integer()
