Some More Tinkering

After yesterday’s discussion of springs and sine graphs, I remembered a post from 2012, “Daydreams, Lectures, and Helices.” I decided to figure out how to graph a helix in R.

Well, after installing the rgl package and experimenting a bit, I got it to work.


Here’s the code:

plot3d(cos(x), sin(y), z, col=”red”, size=3)

I then rotated it into a good view. As my Latin teacher used to say, that’s all there is to it!

Next up (at some point): an animation of a spring.

It’s Too Hard!—No, It Isn’t

In education discussions, when I have suggested that students read Sophocles or Thomas Hardy or study a Newton theorem, people have often exclaimed, “That’s too hard!” (Andrew Hacker provoked outrage when recommending that high schools drop algebra on account of its difficulty, yet variations of his attitude run rampant.)

These works and subjects are not in themselves too hard. Of course, some aspects are quite challenging, even for scholars. Others are easy for a layperson to grasp. There’s a wide range in between. Part of the point of education is to absorb something, to take it into your mind, so that you can return to it later with more understanding.

What I find puzzling is the knee-jerk reaction “That’s too hard!” Why deem anything too hard until you’ve given it a serious try—that is, more than a try? And what’s wrong with a bit of difficulty? Of course if something is too hard, then it’s out of reach for students. But more often than not, when people say “too hard,” they just mean “mildly challenging.”  

In education we often have to consider opposing or counterbalancing principles. One principle is that students need background knowledge in order to comprehend what they read and learn. A good curriculum (such as the Core Knowledge Sequence) builds such knowledge in a thoughtful and logical manner, so that students are prepared for the next stage of study.

A counterbalancing principle is that one can plunge into a seemingly difficult problem or text and figure it out—or at least a great deal of it. Through doing so, one gains insights into the subject beyond the problem. 

To illustrate this, I opened a fairly challenging book to a random page, to see what I’d find there and what sense I could make of it. The book is The C Programming Language by Brian W. Kernighan and Dennis M. Ritchie. It is considered a classic of computer science. On page 113, the authors provide a function that returns a character string containing the name of the n-th month. So, if n = 5, the function will return “May.” Here’s what it looks like:

/* month_name: return name of n-th month*/
char *month_name(int n)
            static char [name[] = {
                        “Illegal month”,
                        “January”, February”, “March”,
                        “April”, “May”, “June”,
                        “July”, “August”, “September”,
                        “October”, “November”, “December”

              return (n < 1 || n > 12) ? name[0] : name[n];

Now, it helps to know just a little bit about programming syntax and logic. But even without that, you can figure out a few interesting things. First of all, look at this list (which is called an array—but you don’t need to know that right now). The first element of the list is “Illegal month.” So, if the elements of the list were numbered 1, 2, 3, and so forth, your function would return “Illegal month” for n = 1 and “January” for n = 2. That doesn’t seem to be what we want.

But look at what it says a few lines down:

return (n < 1 || n > 12) ? name[0] : name[n];

This is clearly telling us to do something specific if n < 1 or n > 12. We’d expect that it would be telling us to return “Illegal month.” We can therefore surmise that “name[0]” refers to “Illegal month.” We can deduce from this that the numbering of the list (the array) begins with 0. The 0th element is “Illegal month”; the first element is “January,” and so on. That is indeed how arrays work.

So now we can interpret that line as follows: “If n < 1 or n > 12, return the 0th element of array ‘name,’ that is, ‘Illegal month’; otherwise, return the n-th element, which is the character string containing the name of the month.”

From there, we can grasp what the syntax actually means. We see that the double lines indicate “or”; the question mark, “if”; and the colon, “otherwise” or “else.”

I grant that I am cheating a little, since I already understand some of this stuff (which is rudimentary anyway; the book gets more challenging than that). But on many occasions, I had to make sense of the above syntax just as I am doing right now. I could bring in a hundred similar examples from literature, languages, mathematics, history, physics, and music.

Again, I’m not saying that we should study computer science or any subject haphazardly. My point is that in many cases, when something seems difficult, you can figure a great deal of it out with a bit of effort. Not only that, but it’s important to do so; such challenge is part of the nature of the subject. A first-rate curriculum includes beautiful, perplexing, and sometimes daunting problems.

What’s the fun of learning, if you don’t get to delve in and struggle a bit? Where’s the reality, if you are never seriously confronted? Where’s the illumination, if the answers are right there before you? Where’s the awe, if nothing is beyond your grasp?