Archive for the ‘math’ Category
Time practice sheet for kids
April 14th, 2008
My second-grader has been learning to tell time, and I wanted to make a set of practice sheets for him. I am, of course, far too lazy to draw the clock faces by hand, or even to use a computer-generated sheet of blank faces and then draw the hands on them. So, following the same principles as my earlier math practice sheet, I made up an HTML document that uses JavaScript’s random number generator to generate a set of clock faces.
My son writes the times below each clock and I (or my wife or my fifth-grader) check his work.
Now, when I say that I “made up” this document, what I really mean to say is that I stole some JavaScript from Mathieu ‘P01’ HENRI. He wrote a realtime JavaScript clock program that draws the hands by altering the height and width of some transparent GIFs that contain diagonal lines. I took a good chunk of the JavaScript and some of the CSS and made an HTML file I named “clock-practice.html.” It’s a bit longer than most of the code I post here, and it’s useless without the set of GIFs for the clock face and the hands, so I’ve wrapped them all together in a zip file you can download from here.
One improvement I’ve made over M. HENRI’s work is to draw the hour hand at the correct angle. If you look carefully at his work, you’ll see that he doesn’t include the minute in his calculation of the angle of the hour hand. This has the unfortunate effect of keeping the hour hand at a constant position from xx:00 through xx:59, which would be very confusing to a second-grader. (In M. HENRI’s defense, he’s using a clock to demonstrate a cute way to draw straight lines at any angle in JavaScript. His focus is not on drawing a clock, per se.)
Every time “clock-practice.html” is loaded or reloaded, it redraws the twelve clock faces with new sets of hands. Whenever I need to make a new set of practice sheets, I repeatedly reload and print the page. To assuage my environmental guilt, I print each page on the back of paper that has already been printed on one side and is headed for the recycling bin.
Octave 3
February 19th, 2008
Today I tried to run Octave on my Intel iMac at work and got this error message:
dyld: Library not loaded: /usr/local/lib/octave-2.9.9/liboctinterp.dylib
Referenced from: /usr/local/bin/octave
Reason: no suitable image found. Did find:
/usr/local/lib/octave-2.9.9/liboctinterp.dylib: stat() failed with errno=62
/usr/local/lib/liboctinterp.dylib: stat() failed with errno=62
This was the first time I’ve run Octave since upgrading the iMac to Leopard, so I suspect there’s been some change in library handling. If I were smarter, or more persistent, I could have spent some time researching the error message and probably would have learned how to get it running again. But since there’s a newer version of Octave now available, I decided to install that instead.
A prebuilt binary of Octave 3.0.0 for the Macintosh can be found at Octave-Forge. It comes as a disk image (dmg) file, and there’s one for Intel Macs and one for PowerPC Macs. You open the disk image and drag Octave.app into your Applications folder, just like any normal Mac application. You can then double-click on it, or launch it via LaunchBar or Quicksilver, and it will open the Terminal and start an Octave session. Which is kind of interesting for a command-line program.
Generally, though, I prefer to start Octave from within an already-running Terminal session. Since the new Octave binary isn’t in my path, I can’t just type octave into the Terminal and get it to launch. So I added this line to my .zshrc file:
alias octave=/Applications/Octave.app/Contents/Resources/bin/octave
I could have added that bin directory to my $PATH, but I wanted to try using an alias instead. The zsh shell allows tab completion on aliases, so I don’t have to type out the full o-c-t-a-v-e. By default, the bash shell doesn’t allow tab completion on aliases, but there’s an extension that will add that feature.
I’m looking forward to trying out Octave’s new sparse matrix support. Last summer, I wrote several special-purpose finite element programs in Octave and might have had shorter runtimes if sparse matrices had been available.
Included in the Octave disk image is a disk image for installing Gnuplot 4.2.2, which is its latest version. This is installed the same way, by dragging Gnuplot.app into the Applications folder. And I added
alias gnuplot=/Applications/Gnuplot.app/Contents/Resources/bin/gnuplot
to my .zshrc file so I could run it directly from the command line.
A bit of playing revealed an odd thing about the Octave/Gnuplot combination: If I start Gnuplot from the command line, the “terminal type” is set to “aqua,” and plots appear in an AquaTerm window. But if I issue a plotting command from within Octave, the plots appear in an xterm window under the X11 application. I have nothing against X11, but I prefer the look of AquaTerm. The solution was to add this line to .zshrc:
export GNUTERM=aqua
Now plot commands within Octave also use AquaTerm.
Although I’m quite happy with these versions of Octave and Gnuplot, I have to say they have the ugliest icons in my Applications folder.
Airplane on a conveyor
January 31st, 2008
I wasn’t able to watch the end of last night’s Mythbusters, but I take it that they got the airplane to take off from an opposite-moving conveyor belt. Not surprising. Also not surprising is that people are still arguing about it. Part of the arguing seems to be based on different interpretations of the problem. Let’s walk through the problem step by step and look at the consequences of the different interpretations.
I’ll start by saying that I have a Ph.D. in engineering and that I used to teach mechanical engineering at a major US university. Further, I taught statics and dynamics courses, the very courses that deal with the issues at hand. This will, of course, mean nothing to the great self-appointed experts of the internet, but I think it’s worth a mention. Onward.
There are three things about the problem setup that everyone seems to agree on. First, there is a speed, call it v0, that the airplane needs to achieve to take off from a normal, stationary runway. Second, the top surface of the conveyor is set to move at this same constant speed, v0. Third, the airplane is placed on the conveyor with its nose pointing in the direction opposite the motion of the conveyor. (I.e., if the top surface of the conveyor is traveling south, the plane is pointed north.)
At this point there’s a fork in the way people interpret the problem. You can assume:
- The engine speed of the plane on the conveyor is set to the same speed as it would be when taking of from a normal runway, which means that the propellor is producing the same thrust. This will lead to an airplane body speed (or wing speed) of v0 relative to the ground and the surrounding air. Since it is the wing speed relative to the air that produces lift, the plane will take off. This is what the Mythbusters assumed and is how they set up their tests.
Or you can assume:
- The body speed of the plane relative to the conveyor is set to the normal takeoff speed, v0. This will lead to a wing speed of zero relative to the ground. There will be no lift and the airplane will not take off. It turns out, though, that the engine speed needed to achieve this body or wing speed is much, much less than the engine speed needed for a normal takeoff.
I suspect that a lot of people think you can have it both ways: an engine speed equal to that of normal takeoff and a body speed of v0 relative to the conveyor. That, in fact, is the trick of the problem. But you can’t have it both ways.
Here’s a side view of an old biplane that I lifted from this site. I’ve added the arrows that represent the forces that act on the plane as it’s trying to take off. This sort of drawing is called a free body diagram and is one of the fundamental tools for solving mechanics problems.
If we assume the first scenario, with the engine speed equal to that of a normal takeoff, the thrust will be much higher than the sum of the drag and friction forces, and the plane will accelerate to the left. (The friction force won’t increase much as the speed increases and won’t be significantly different from the friction in a normal takeoff.) Eventually, the plane will reach a speed relative to the ground and air where the lift forces at the wings will be greater than the weight. At this point, the contact force will drop to zero and the plane will take off.
If we assume the second scenario, with the body speed of the plane relative to the ground and the air of zero, the drag force will be zero (because the wings won’t be moving relative to the air). Since the plane is stationary relative to the ground, its horizontal acceleration is zero and its horizontal forces must be balanced. Therefore, the engine will only have to provide enough thrust to balance the relatively small friction at the wheels. This is much less thrust than is required for the first scenario, so the engine speed will also have to be much less than in the first scenario.
The upshot is you can’t have a stationary plane with its engine running like it would for a normal takeoff. You have to pick one or the other.
[Those of you familiar with free body diagrams may take issue with where I’ve placed some of the forces. Me too. I know the moments aren’t in balance, but I wanted to keep force arrows separated enough to be easy to distinguish. If moment equilibrium were important to the problem I’d be more careful where I drew the arrows.]
If you’re wondering why the thrust is forward rather than backward, the explanation is that while the propellor is pushing back on the air, the air is pushing forward on the propellor. Newton’s third law. It’s the same reason you’re able to walk forward: your feet push back on the ground and the ground pushes forward on your feet.
The smooth math search
March 6th, 2006
I’ve tried out several math programs, hoping to find one that’s both general enough to handle the variety of problems I need to solve and natural enough in its syntax that I don’t have to think about how to do the input for simple problems. I’m basically looking for a super calculator, something that I can use interactively and write simple programs for. Apart from the various Matlabish programs, I’ve looked into
- Lush: The parentheses don’t bother me, but prefix notation just doesn’t seem natural for math.
- R: Great for statistics, but too much notational fussiness for other matrix problems.
- Numerical Python: Always seems to getting forked and rebuilt; I’m afraid of choosing an orphaned version.
- Numerical Ruby: Not ready yet?
- PDL: I like Perl, and I have never had the disgust with its syntax that others seem to, but the PDL notation just doesn’t seem right.
I’m beginning to think that Octave is as close as I’m going to get to my ideal, and I should concentrate on learning it well. I don’t know that it’s better than the similar programs RLab, SciLab, or Yorick, but it’s what I’ve used the most and I haven’t seen a compelling reason to switch among this group. (In gathering the links for this post, I learned that SciLab has some form of sparse matrix support, which makes it worth looking at a little more closely.)
One thing Octave is lacking is a set of trig functions for dealing with angles given in degrees. The conversion isn’t difficult, of course, but it’s a pain to type all those *pi/180s. I made a .octaverc file with the following definitions to eliminate some of the extra typing. The new function names are simply the radian-based function names with a “d” appended to them.
function retval = sind(x)
retval=sin(x*pi/180)
endfunction
function retval = cosd(x)
retval=cos(x*pi/180)
endfunction
function retval = tand(x)
retval=tan(x*pi/180)
endfunction
function retval = secd(x)
retval=sec(x*pi/180)
endfunction
function retval = cscd(x)
retval=csc(x*pi/180)
endfunction
function retval = cotd(x)
retval=cot(x*pi/180)
endfunction
function retval = asind(x)
retval=asin(x)*180/pi
endfunction
function retval = acosd(x)
retval=acos(x)*180/pi
endfunction
function retval = atand(x)
retval=atan(x)*180/pi
endfunction
function retval = atan2d(x, y)
retval=atan2(x,y)*180/pi
endfunction
function retval = asecd(x)
retval=asec(x)*180/pi
endfunction
function retval = acscd(x)
retval=acsc(x)*180/pi
endfunction
function retval = acotd(x)
retval=acot(x)*180/pi
endfunction
Simple, but useful.
Squares and square roots again
August 18th, 2005
A few days ago, I was looking up information on mechanical calculators (don’t ask). I ran across an article on the Friden SRW, which had the ability to extract square roots with the push of a single button. This was a big deal for a device consisting of motor-driven gears. As it turns out, the algorithm used to get the root was based on the summation of odd integers trick that I had just learned a couple of weeks ago. Maybe this is a sign that I should quit my job and study number theory. Or maybe it’s a sign that I spend too much time looking at nerdy things on the Internet.
Fun with integers
August 18th, 2005
The other day I was looking at Andy Hertzfeld’s folklore.org site, which consists of a series of anecdotes about the creation of the original Macintosh computer. Most of the stories—there are over a hundred—were written be Andy himself, but there are several guest contributors. It’s a fun site to hop around in if you were one of the early Mac users and can remember its programs and how they worked. (I will always revere Andy for writing Switcher, a program I always thought was better than the later MultiFinder. I wish Linux window managers had that cool Lazy Susan screen animation.)
One of the stories is about Steve Jobs persuading Bill Atkinson to add rounded-corner rectangles to the QuickDraw portion of the Mac Toolbox. It’s a good story, one that illustrates the good and bad parts of Jobs’s personality in a just a few words. I’d read other versions of the story before, but Andy’s telling has this odd arithmetic fact:
Bill’s technique [of drawing ovals and circles] used the fact the sum of a sequence of odd numbers is always the next perfect square (For example, 1 + 3 = 4, 1 + 3 + 5 = 9, 1 + 3 + 5 + 7 = 16, etc). So he could figure out when to bump the dependent coordinate value by iterating in a loop until a threshold was exceeded. This allowed QuickDraw to draw ovals very quickly.
I had never before heard that the sum of a sequence of consecutive odd numbers always adds to a perfect square. In fact, after looking at it a while, I saw that the rule was even better than Andy says: the sum of the first n odd digits is the square of n. What a bizarre and beautiful result! I had to figure out why it works.
If you’ve ever heard the story of the young Carl Fredrich Gauss adding all the integers from one to one hundred, you’ll know where I got the idea for what follows. Start by writing out the sum as you normally would:
1 + 3 + 5 + ... + (2n-1)
Note that (2n-1) is the nth odd number. Now underneath that sum, write it again, but this time going from high to low.
1 + 3 + 5 + ... + (2n-1)
(2n-1) + (2n-3) + (2n-5) + ... + 1
Now add these two sums column-wise.
1 + 3 + 5 + ... + (2n-1)
(2n-1) + (2n-3) + (2n-5) + ... + 1
---------------------------------------
2n + 2n + 2n + ... + 2n
Each pair of terms adds to 2n, and there are n of them, so the sum is 2n2. Because we’ve added all the odd numbers twice, this is twice the number we’re looking for. Therefore, the sum of the first n odd digits is n2.
Since I’m no Bill Atkinson and I’m not trying to write a graphics library for a machine with no floating point processor, I have no idea how I could use this fact. But it’s worth knowing just for the sake of it’s beauty and simplicity. And it’s good to know that my middle-aged brain can still do arithmetic.