> = excerpts from post by Ladnor Geissinger,
Math Dept, Univ of NC Chapel Hill
to k12.ed.math (Oct 17, 1999)
>I recently read the call for proposals for the Working Group for
>Action 2 at the ICME-9. It focuses on what it claims is the main
>characteristic of junior secondary school, that it is a time of
>transition. It then says:
>
>In the Mathematical context, the main problem of transition is
>characterized by the necessity of introducing such important and new
>issues as:
>--variables and functions, both as concepts and as symbols with a deep
>novelty with respect to the epistemological status of arithmetical
>knowledge and language, to which students have been acquainted during
>the elementary school; all this puts on the table the problem of the
>transition from arithmetic to early algebra.
>-- ... etc
>
>To my ear this sounds like the musings of a medieval philosopher on
>how to crowd angels on the head of a pin. The supposed problem seems
>to be overblown if indeed it exists, and seems to be of the sort that
>would not exist if teachers and texts had not treated things
>unnaturally and made mysteries out of the ordinary.
I agree with your assessment.
>What do we ordinarily do with a well-defined process that we think
>would be very useful to carry out on lots of specific objects? We
>build a device/machine to automate the process - to save ourselves
>time and energy. We do the same in math.
Exactly. I agree completely that a good approach to math
is showing how a specific solution is going to be applicable
to a wide range of similar problems -- we just need to figure
out what the variables are going to be, and write our solution
in a way which accomodates such variations.
The analogy with mechanisms is well-conceived, especially when
you recognize that mechanisms often come with control panels
where the whole point of the controls is to alter the variables
e.g. the sequence of digits punched when dialing a phone
number. Likewise, the whole point of instruments (indicators)
on a control panel is to display variable output from the system
(dial tone, busy signal, ring etc. are auditory indicators of
the phone's "internal state" -- modems come with an even
richer set of states and a language for setting/getting
those states).
>mechanism). And by the way, where else do they get to make up their
>own devices and play with them -- shouldn't this be a magnet for
>the independent minded middle schooler, the anarchic teenager? Has
>something gone wrong - have we succeeded in repressing the instinct to
>look for patterns, design and build devices and investigate and play
>with math objects - the most universal and accessible (not to mention
>useful) artifacts of civilization?
>
Yes, the ability to design and implement your own devices is
a potentially big draw in math class. To what extent to we
as educators actually encourage this kind of experimentation
in math class?
What I think math classes are missing in many instances is
access to computers and a suitable programming language. The
concept of a "mathematical object" gets valuable reinforcement
when you see how "objects" consist of properties (which record
the internal "state" of an entity) and methods (which accept
input from outside the object, and use that input to make
changes to the internal state).
Hewlett-Packard has a very visual environment called HP VEE,
which allows users to drag XY graph displays from a toolbox,
and wire these up to signal generators of various types. You
fill your screen with "objects" (mostly rectangular) which
have inputs and outputs (called "pins"). By dragging the
mouse, you wire the output pins of one object to the input
pins of another. Each object comes with internal properties
which let the user modify its appearance and behavior.
More applications of this kind, which give students an
intuitive and consistent metaphor (e.g. objects networked
by wires), and which encourage a "design your own and
test/debug it" experience, would be a real door-opener
for many (including many who do not enjoy math as presented
today). Just getting by with text books and the occasional
graphing calculator is insufficient in my book -- does way
too little to take advantage of the many ways technology
has evolved to make educators' dreams come true.
>One of the common things we do in using language is to NAME things,
>and then use the name in sentences about the things -- this is direct
>reference. We also have PRONOUNS which we use in sentences as an
>alternative or indirect reference to an object, and then we don't know
>until context or something else tells us which specific object the
>pronoun was intended to refer to. Children are exposed to these uses
>of language and learn early how it works -- we don't push off learning
>to use pronouns until somewhere in middle school and then treat it as
>a new and difficult topic.
One thing that's so useful about the objects model is that
you can encapsulate a lot of functionality inside an object,
and then give it a name. Then you can define other objects
which accept variable input, where the variables stand for
_objects_, not just _numeric values_. The concept of
"variable" is thereby expanded to include "names of objects",
where these objects may, in turn, have a lot of internal
structure (including other objects).
For example, a polyhedron, with the ability to grow/shrink,
rotate, translate, change its colors, display as wireframe
or "solid", is an object. Then you might have other objects
which accept polyhedra as input, and scan their internals
in order to generate output files -- say a text file
with the syntax needed to drive a rendering engine or
VRML browser. The notation for expressing these ideas
might look something like this:
zippy = Tetra() # zippy names a Tetrahedron
zippy.facecolor = 'Blue' # ... with blue faces
pumpkin = Icosa() # pumpkin names an Icosahedron
icosaobj.facecolor = 'Orange' # ... with orange faces
icosaobj.edgecolor = 'Black' # ... and black edges
scriptomatic = POVwriter('myfile.pov') # another kind of object
scriptomatic(zippy) # automatically writes to a file
filewriter(pumpkin) # taking polyhedron objects as input
filewriter.closefile() # file now ready for ray tracer
Notice how the filewriter object accepts polyhedra as input.
We start to think of names as tags at the end of a string.
When you pull on the string, what you find at the other end
might not be so simple as a numeric value (e.g. 33). It
might be an object, and that object may have lots of controls
and instruments associated with it.
Kirby
Note: My ideas for using the "objects" metaphor from computer
science to further enhance the K-16 math curriculum are
written up in some detail, and linked to specific examples,
at my Oregon Curriculum Network website.
See: http://www.inetarena.com/~pdx4d/ocn/trends2000.html
****************************************************************************
* To post to the list: email mathedcc@archives.math.utk.edu *
* To unsubscribe, send mail to: majordomo@archives.math.utk.edu *
* In the mail message, enter ONLY the words: unsubscribe mathedcc *
* Words in the Subject: line are NOT processed! *
* Archives at http://archives.math.utk.edu/hypermail/mathedcc/ *
****************************************************************************