reducing fractions

[krisclark3 at home.com]

You need to use some pictures and manipulatives first so that they
understand conceptually that 1/2 looks like 2/4 and 4/8.  How are they
different?  Note how 4/8 is shaded the same as 1/2 but divided up
differently.  Then look at the number of pieces each section is divided
into.  This will give you the factors.
After they "see" it, move to the paper and pencil stuff.  Show them how 2/4
is the same as 1x2/2x2.  Divide it into 2/4=1/2 x 2/2.  They know that 2/2
is the same as one, so 2/4=1/2x1=1/2.
But the conceptual stuff is the most important.  Let them do the work in
figuring out how to do it.  Once they understand it, the algorithm will be
much more acceptable to them.
"Kirby Urner" <urner at alumni.princeton.edu> wrote in message
news:lalgpsou36vvrrbhnj2hr0qapk955p3fdc at 4ax.com...
> "Janet Johnson" <johnsonje at adelphia.net> wrote:
>
> >I teach 6th grade and every year my students seem to have a lot of
> >difficulty with fractions, specifically, reducing or recognizing that a
> >fraction isn't reduced.  I have given them many ideas on how to tell,
even
> >to the point of writing out the factors for both the numerator and
> >denominator.  Does anyone have any suggestions on how to get this concept
> >across to the students?  Any suggestions would be greatly appreciated.
> >Janet Johnson
>
> You could unsimplify some fractions e.g. 2/3 -> 10/15
> i.e. show the inverse of what it means to "simplify".
>
> If 'prime number' is already a concept, you could try
> 'relative prime' meaning no factors in common (i.e.
> "a fraction is in lowest terms when the numerator and
> denominator are both integers and are relative primes").
>
> Along these lines, I really like your idea of writing
> out the prime factors, crossing out those in common e.g.:
>
>    150/210 -> (3 x 5 x 2 x 5) / (7 x 3 x 2 x 5) -> 5/7
>
> That ties back to "intersection of sets" i.e. the
> intersection of {3,5,2,5} and {7,3,2,5} is {3,5,2}
> (multiple appearances of the same factor constitute
> unique members of each set).
>
> As the other poster mentioned, you're looking for the
> greatest common divisor or "biggest gzinta (goes into)",
> in the above example 3 x 2 x 5 = 30.
>
> Pictorially, you could do a pie divided into 3 wedges
> (thirds) and then slice each third in half (sixths).
> Getting 1/3 of the pie is the same as getting 2 x 1/6s
> or 2/6s.  Lots of pictorials along these lines -- including
> in 3D (i.e. volumes in space).[1]
>
> Historically speaking, finding the greatest common
> divisor (gcd) is one of the oldest algorithms on record,
> and is credited to Euclid.
>
> Here's how Euclid did it:
>
> Setup:  Consider two numbers a and b.  Which is greater?
>         Lets say a (call the other one b).
>
> Step 1: Divide a by b.
>
> Step 2: If it goes evenly (remainder = 0), we're done,
>         and b is the gcd.
>
> Step 3: If there's a remainder r > 0, then we can
>         refocus the problem to finding the gcd between
>         b and r.  So rename b, r to a,b and loop to
>         step 1.
>
> Note that 1 always goes evenly, so if the remainder is
> 1 in Step 3, we'll get 1 as the answer in Step 2 --
> which is OK.  A gcd of 1 means a,b are relative primes.
>
> Trying the above with b=150 and a=210 i.e. gcd(210,150):
>
> Step 1,2:  210/150 -> remainder of 60
> Step 3:    now find gcd(150,60)
> Step 1,2:  150/60 -> remainder of 30
> Step 3:    now find gcd(60,30)
> Step 1,2:  60/30 -> remainder of 0, so answer is 30
>
> In a well-equipped math classroom, one with an internet hookup and
> a projected computer screen (big up front), I'd show students
> (even 6th graders) some of these ideas using Python notation (a
> free download, no strings attached).[2]
>
> You can use the % primitive to get the remainder, i.e. a%b ->
> remainder of a divided by b.  Here's what that looks like
> (>>> is the prompt (teacher types), with the next line, in a
> different color, being Python's reply):
>
>  Python 1.6a2 (#0, Apr  6 2000, 11:45:12) [MSC 32 bit (Intel)] on win32
>  Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>  IDLE 0.6 -- press F1 for help
>
>  >>> 210%150
>  60
>  >>> 150%60
>  30
>
> You could even show a little program implementing Euclid's
> algorithm.  Here's one way to write it:
>
>  >>> def gcd(a,b):
>          while 1:          # loop until break
>             r = a%b        # step 1
>     if r == 0:     # step 2
>         break      # we're done
>     else:
>         a,b = b,r  # step 3
> return b
>
>  >>> gcd(210,150)
>  30
>
> Here's another way (even shorter):
>
>  >>> def gcd(a,b):
>          r = a%b                 # step 1
>          if r == 0:              # step 2
>      return b
> else:
>      return gcd(b,r)     # step 3
>
>  >>> gcd(210,150)
>  30
>
> It's fun to have a computer in the picture because then you
> can play with larger numbers than in the text books, or than
> calculators can handle.
>
> For example:
>
>  >>> gcd(72534982347852342L,6276912736644L)
>  6L
>
> The L mean "long integer" and cues Python that we're going
> beyond the scope of "ordinary" integers (a type casting
> consideration handled more transparently in another language,
> also a free download, DrScheme).[3]
>
> Here's one way to write gcd using DrScheme:
>
> Function:
>
>  ; gcd: number number -> number
>  ; to find the gcd of two numbers (Euclid's Algorithm)
>  (define (gcd a b)
>      (define r (remainder a b))
>      (cond
>        [(= r 0) b]
>        [else (gcd b r)])
>  )
>
> Usage:
>
>   Welcome to DrScheme, version 101.
>   Language: Textual Full Scheme (MzScheme).
>   > (gcd 210 150)
>   30
>   > (gcd 72534982347852342 6276912736644)
>   6
>
> So the above gcd means:
>
>     6276912736644/72534982347852342
>  -> (6 x 1046152122774)/(6 x 12089163724642057)  [practice long division!]
>  -> 1046152122774/12089163724642057
>
> and 1046152122774, 12089163724642057 should be relative primes,
> since we've already divided by the gcd.  Checking:
>
> Python:
>
>  >>> gcd(12089163724642057L, 1046152122774L)
>  1L
>
> DrScheme:
>
>  > (gcd 12089163724642057 1046152122774)
>  1
>
> Yep!
>
> Long division problem (good to show because calculators and
> even floating point processors choke on this many digits,
> but our paper and pencil algorithms do not):
>
>       12089163724642057
>       ------------------
>     6|72534982347852342
>
> Doing a long divisions such as the above on paper needn't
> be too tedious if the whole class works together a few times.
> Good review of the times table for 6.
>
> I teach putting the remainder as a tiny digit to the upper
> left of the next, so we don't have this huge long series of
> subtractions trailing down like the tendrils of a jelly fish.
>
> E.g. 6|7... leaves 1, so the 1 goes to the upper left of
> the 2, making 12, and so on (I'm sure all the K-12 math
> teachers know what I mean).
>
> I think it's important to clue kids early about these limitations
> of floating point and even long integer arithmetic on computers,
> plus most calculators won't even touch 17-digit numbers (or
> greater).  As I wrote re the Math Summit in Oregon (1997):
>
>   "(as the official note taker, I managed to interject twice
>    -- once about the wierdnesses in floating point math as
>    implemented in computers, reason enough to learn the
>    algorithms on paper as well)"[4]
>
> I.e. this is how to respond to students who ask why we're still
> learning long division on paper when we have calculators and
> computers:  because calculators wimp out, and with computers
> you may need to check its math, especially if any floating
> point operations were involved.
>
> For example in Python, using floating point:
>
>  >>> 72534982347852342.0/6.0
>  12089163724642056.0
>
> Which is off by a digit (because of the limited precision of
> floating point numbers).
>
> DrScheme gives the same answer, but warns the result is
> imprecise using the # symbol.  From the manual:
>
>   * Print inexact numbers with #i -- Prints inexact numbers
>   with a leading #i to emphasize that they represent
>   imprecise results (or even effectively incorrect results,
>   depending on the intended calculation).
>
>  > 72534982347852342/6.0
>  #i12089163724642056.0
>
> If the above were really the right answer, then 72534982347852342
> should be divisible by 36, since 12089163724642056 is again
> divisible by 6.  Python might lead us to believe this is true,
> because the / operator is designed to give only integer answers
> no matter what -- unless one of the arguments is floating point
> (i.e. we'll get the wrong answer whether we use / as an integer
> or floating point operator in this case).
>
> So:
>
>  >>> 72534982347852342L/36L
>  2014860620773676L
>
> -- but we can't really trust this result.  The way to check is
> to ask for a remainder is to use the % operator:
>
>   >>> 72534982347852342L%36L
>   6L
>
> .... which shows 36 isn't really a 'gzinto'.
>
> DrScheme doesn't implement the / operator in the same way, and
> 72534982347852342/36 gives a correct answer, a fraction:
>
>  > 72534982347852342/36
>  12089163724642057/6
>
>
> Kirby
>
> [1] Too much emphasis on cubes and rectangular prisms when
>     doing fractions leaves students deprived of a stronger
>     conceptual grasp of polyhedra, which derives from using
>     a richer set of fractional relationships.  My school is
>     very much into using a modularized set of polyhedra with
>     easy whole number and fractional relationships, as per
>     my web pages: http://www.teleport.com/~pdx4d/volumes.html
> [2] http://www.python.org/sigs/edu-sig/
> [3] http://www.cs.rice.edu/CS/PLT/Teaching/
> [4] http://www.teleport.com/~pdx4d/mathsummit.html


----------------------------
submissions: post to k12.ed.math or e-mail to k12math at sd28.bc.ca
private e-mail to the k12.ed.math moderator: kem-moderator at thinkspot.net
newsgroup website: http://www.thinkspot.net/k12math/
newsgroup charter: http://www.thinkspot.net/k12math/charter.html