Drexel dragonThe Math ForumDonate to the Math Forum



Search All of the Math Forum:

Views expressed in these public forums are not endorsed by Drexel University or The Math Forum.


Math Forum » Discussions » Education » math-teach

Topic: Algorithms, long division in particular
Replies: 3   Last Post: Feb 24, 1995 6:47 PM

Advanced Search

Back to Topic List Back to Topic List Jump to Tree View Jump to Tree View   Messages: [ Previous | Next ]
David Scott Powell

Posts: 54
Registered: 12/6/04
Re: Algorithms, long division in particular
Posted: Feb 24, 1995 5:37 PM
  Click to see the message monospaced in plain text Plain Text   Click to reply to this topic Reply

>This is a long posting, so if you are not interested or in a hurry,
>perhaps you might want to skip it or save it for later.
>
>On Thu, 23 Feb 1995, Tad Watanabe wrote:
>

>> On Thu, 23 Feb 1995, Edward S. Miller wrote:
>>

>> > Now for my personal spin on algorithms. Humans have spent countless
>> > effort to develop efficient means for accomplishing all sorts of tasks.
>> > In mathematics, we see dozens or thousands of algorithms put to use,
>> > depending on our level of immersion and experience. The long division
>> > algorithm and the multiple digit multiplication algorithm (again, the
>> > one I use based on the distributive law) are the earliest instances I
>> > recall of iterated algorithms with multiple _different_ operations;
>> > division is the first with a nontrivial ending condition.

>>
>> Could you expand on this a little?

>
>Certainly. In the algorithm I call long division, when approaching 345
>divided by 16, my first step is to compare 16 to 34 and decide (usually
>by estimation, sometimes by emulating the next specified step) that 16 is
>about half of 34. I need then multiply 16 by 2. Then I subtract32 from
>34. I carry down a digit. Then I iterate the process. I stop when the
>remaining number is actually less than my divisor.
>
>I have to start with the appropriate bookkeeping technique to preserve
>digit alignment. Sometimes, but not in this particular problem, the carry
>down still doesn't make the current step dividend large enough, so I
>carry down another digit; I don't just stop. I also have to place a
>zero in the appropriate position of the quotient because of our
>positional numeration system.
>
>There are multiple other arithmetic operations involved in the algorithm
>as well as estimation skills. The decision to terminate is unlike the
>multiplication algorithm stop point in the sense that you can't just keep
>on until you have nothing to work with.
>
>As for understanding the algorithm, in the case of no remainder problems,
>the algorithm is literally the reverse of the multiplication algorithm
>except that the rows would be added one at a time instead of all at
>once. Each single digit multiplication is present and executed. Try
>doing 42 times 37 and then 1554 divided by 42. The remainder, of course,
>complicates things a little but divisions with remainders can be viewed
>as the reverse of a compound multiplication and addition exercise.
>

>> >
>> > Throughout subsequent mathematics we encounter such algorithms of all
>> > types. Sometimes, in "real life," for physical, temporal, or economic
>> > reasons, it is necessary to use algorithms for single or repeated
>> > operations. We do need to teach our students how to apply algorithms. I
>> > happen to prefer long division because if we have to wait for
>> > factoring or Euclid's algorthm or Horner's algorithm or L'Hopital's rule,
>> > we're dead before we start.
>> >

>>
>> But you are not advocating teaching in the sense of imposing algorithms
>> on students whether or not they make sense, are you? Or, are you saying
>> that there are contexts in schooling (which I happen to believe is a part
>> of "real" life), there are occasions we should?
>>

>
>In reverse order, I meant "real life" as opposed to objects and actions
>which only exist in thoughts and discussions without being actualized.
>For example, many fine discussions about strategies for and consequences
>of colonizing other planets have happened, but planets have not been
>colonized (by humans, at least) in "real life". Of course "real life"
>includes schooling. Sorry if that wasn't clear.
>
>An example of an algorithm used in "real life" schooling for physical and
>economic reasons is when I actually, in the middle of some other problem,
> / 2
>evaluate |x sin x dx by hand using integration by parts twice because
> /
>I don't happen to have a computer handy in class that day. Honest, it
>happens on Mondays and Wednesdays in calculus.
>
>Furthermore, there are times when it is necessary to just learn when an
>algorithm is applicable and how to use it for the sake of expedience (in
>non-schooling situations, at least). I learned the braking algorithm for
>my car, I know it doesn't often work on ice, but I certainly didn't
>design a brake nor did I invent the concept of braking independently.
>Sometimes it is necessary to go with thousands of years of accumulated
>human knowledge and methods in some areas so that you can think in
>others. An interesting account along these lines is contained in the
>book "Planet of the Apes" by Pierre Boulle.
>
>And finally, I never "impose" an algorithm on a student or anyone else
>for that matter. I do demonstrate algorithms which I think make sense
>(or perhaps more accurately, which I think will make sense to the
>audience) and try to help the students understand it at some level.
>I rarely try to prove that an algorithm works in a rigorous way until the
>precalculus/calculus stage of the game.
>
>On the other hand, if a student uses a self-developed algorithm or one
>learned from someone other than myself with which I am not familiar, I
>try to prove it rigorously for myself. If I do, I allow the student to
>use it. If I find a counterexample I either provide it to the student or
>give a good hint, depending on the nature of the example. Sometimes I am
>stuck without proof or counterexample, in which case I caution the
>student that the algorithm may be unreliable and ask her to convince
>me that it is. Sometimes she does and sometimes she doesn't. If she
>does, I allow its use; If she doesn't, I do not allow its use.
>
>After ten years in the classroom, not a single class goes by where I do
>not improve one of my own algorithms and where no student shows me one I
>haven't seen before which works as well or better than the one I use. On
>the other hand, some 20 years after learning long division, it is still
>the algorithm which makes the most sense to me.
>
>--Ed
>
>
>-------------------------------------------------------------
>Edward S. Miller edmiller@lcsc.edu
>
>Division of Natural Sciences VOICE 208-799-2810
>Lewis-Clark State College FAX 208-799-2064
>500 8th Avenue
>Lewiston ID 83501-2698 USA
>-------------------------------------------------------------


Just a couple of points. When you say that there are just some algorithms
that you have to just do what do you use to justify that statement. Do you
want students to just blindly use them because of expedience, really?
Wouldn't it be better if students were taught to think about why things
work rather than blindly accepting something. You yourself say that when a
student comes up with one you test it out(when you prove or disprove do you
really understand what is going on?)first before you just accept it? Do
you automatically assume the author of your car manual is correct? Doesn't
it have to kind of make sense first? Hmm... pretty deep for friday, huh?
scott

Scott Powell
University Lab School
1776 University Ave.
Honolulu, HI 96826
(808)956-4987wk
dpowell@math.ed.hawaii.edu







Point your RSS reader here for a feed of the latest messages in this topic.

[Privacy Policy] [Terms of Use]

© Drexel University 1994-2014. All Rights Reserved.
The Math Forum is a research and educational enterprise of the Drexel University School of Education.