Search All of the Math Forum:

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

Topic: Brainstorming about STEM (was About Functions)
Replies: 49   Last Post: Jan 13, 2012 2:37 PM

 Messages: [ Previous | Next ]
 kirby urner Posts: 3,690 Registered: 11/29/05
Re: Brainstorming about STEM (was About Functions)
Posted: Dec 13, 2011 12:54 PM

On Mon, Dec 12, 2011 at 10:48 PM, Dan Christensen <dc@dcproof.com> wrote:

> [snip]
>
> How do you change a set into something that is not a set? You have to be consistent.
>

The builtin types all have names, such as int, list, tuple, set, dict.

These names are what we call "callables" meaning they can eat
arguments, like functions can, but they're not technically names
of functions.

>>> B = set ( [ f(x) for x in A ] ) # using set as a callable (# for comment)

would turn B into a set. It might have a lot fewer members
than set A as many f(x) could map to the same set element
in B.

>> We can use sets to purge dupes out of lists.
>
> You can look at lists as functions mapping N (the set of natural numbers) to some set, possibly N itself. I suppose, you could look at the range (or codomain) of these functions as a "list" purged of duplicates.
>

Yes. What I'm suggesting though is we appropriate the
technical jargon and concepts around functions, as
conventionally introduced, and custom fit these to include
a wider sampling of inputs and outputs (forget about
numbers for awhile).

Sticking with natural numbers, integers or even number
types in general is far too restrictive.

We need many more examples of functions that "eat"
letters or strings, lists, sets (as arguments), any kind
of object.

A goal here is to break the ethnic convention, instilled
by conventional math books, that when you're talking
about operations, functions, algorithms -- the "doing"
of K-12 mathematics -- that you're thereby in the world
of "number crunching".

Related excerpt from 1999 trade industry mag where
I pound the table as Silicon Forest exec, in case
anyone cares what industry thinks:

>
> You are using the word "function" in at least two different ways. It might confuse students. There are biological or mechanical functions and computer software functions -- all involving actions of some kind, be they actions of electrons, molecules, cells or larger parts in the physical world -- and there are mathematical functions that are abstract relationships between two or more sets of objects. (And others, I'm sure.)
>

That "might confuse" needs to be turned into "might enlighten" i.e.
these family resemblances and partial overlaps in meaning are not to
be bleeped over, as if inconveniences to which we must turn a blind
eye.

On the contrary, a "domain" could be very like a kingdom, with the
parabolic function a way of hitting a target on a firing "range" over
there, the physics activity of using a gun, trebuchet or catapult now
in the picture.

Why did the concept of "function" ever arise as important within
mathematics? Do we care? Are we to presume that ballistics was never
important or that the military origins of mathematical concepts (some
of them) should be left off camera?

On the contrary, we slog through long units on SQL that are vividly
historical in their examination of various "eugenics" theses /
hypotheses, right back to Plato. People trying to sort other people
by attribute, store names in files. The basis of medical records
keeping, needed for benign purposes as well as nefarious. I did a
workshop on this for STEM teachers in 2009 at Hyatt near O'Hare in
Chicago, have the vid on BlipTV.

When it comes to computer language, we see these primitive objects
bonding into functions, which eat arguments and do work (return work).

These functions then morph into methods of classes, which doesn't
happen in Dolciani or SMSG, but does happen along our DM track. It's
a lot like evolution, with functions as like cells and classes more
like organisms, even developing a backbone:

class Snake:
def __rib__(self):
pass
def __rib__(self):
pass
def __rib__(self):
pass
def __rib__(self):
pass

- -- looks like a head with a body of ribs (our triggered methods, reflex arcs).

We're feeding object oriented programmers directly to industry,
bypassing California's education system completely (which is fine for
them -- plenty of students in need of services there already, without
needing any of Oregon's or Alaska's).

We do a lot more at home, sometimes paying families for time on their
equipment the student needs (TECC model).

>> becomes more standard that way, which advantages my
>> home faculty in Sebastopol (the base) if and when.
>>

>
> California?
>

Right. Probably the biggest employer in town. Out of town its the
growers of various types. Humbolt, Mendecino... you know the area
perhaps, wine country.

>
> I make no use of truth tables. Rather, I use my own simplified form of natural deduction.
>

Interesting. I was just dreaming up how to permute all the possible
True / False combinations for n names in a proposition.

I had elected to go binary naturally, which counts up through the
permutations as it goes. 000 001 010 011... 111.

prop = "(not p or not q) == (not (p and q))"

The above is a string type object, expressed literally (as a string
literal), that is also a valid expression given p, q are boolean
objects, signified as True and False.

for p, q in ((True, True), (True, False), (False, True), (False,
False)): print ( eval ( prop ) )

would be a way of running a truth table (domain) through the function
(prop) to get a result (printed range).

The actual example in Sebastapol is: write a string that's all
uppercase (p) and ends with a period (q).

So then the program needs to look at user input (through input) and
test for p and q against the sentence, flagging violations.

What we don't have them do (yet) is worry about boolean expressions of
the type shown above, or truth table domains.

That would be for a next course in our track maybe, using this popular
language (I call myself "a logic teacher -- mechanized division" (has
a ring to it)).

But I'm a logic teacher in the context of STEM which means I don't
support the hyper-specialization trends which have turned delicate
strands of relevance between disciplines into scary "confusion" or
"mush".

>
> While it certainly has its application in many areas, I don't think geometry is best way to teach proofs as encountered in advanced math courses. See "To the Educator" at my website.
>

I'm OK with other approaches too. I like "visual proofs" or things
that appear to prove other things, what some might call
"demonstrations" or even "explanations" (like showing how a magic
trick works).

Again, my curriculum stresses geographic / ethnographic roots of
concepts, with formal proof / axiom narratives applied
retrospectively. That's not where math starts.

People were doing mathy things, and continue doing so, independently
of the theorem / axiom dogmas, and we investigate that, trace an
historical process whereby formalization / optimization comes after a
lag time, with exploration happening first. Early adopters start
working with applications well before the janitors come along and make
it all tidy after the fact.

We follow Wolfram in taking the computer to be a kind of laboratory
where experiments might be run. Learning our curriculum with no
computers would be an oxymoron and cannot be done, not even in New
Zealand (where they have Computer Science Unplugged or whatever it's
called).

On the other hand, we accept students with no computer experience.
Just because you have Lion and Ubuntu on VirtualBox on Win7 doesn't
make you a shoo-in for our pilots in Portland. Do you know anything
about cooking, using knives, sanitation, camping? Teachers have rank
along such axes.

>>
>> I haven't found the tutorial yet.  Is it a PDF?

>
> It's part of the Help file in my program. There is a brief excerpt at my website: Click on "Features," scroll down, click on "View table of contents and excerpt."
>

>>
>> I'm interesting in the segments linking boolean
>> expressions to logic
>> gates.

>
> You can introduce propositional logic using my program, but maybe an approach based on truth tables might be a productive for circuit design.
>

I'm used to brute forcing through truth tables as a test of all
possible permutations of boolean values for p,q,r... in expressions,
which may be logical "rules".

If the last column is "all True", then that's a wrap, the circuit you
need (in this game -- in reality you define inputs and outputs as
permutations to be matched).

Kirby
www.4dsolutions.net

> Dan
> www.dcproof.com

Date Subject Author
12/11/11 kirby urner
12/12/11 Dan Christensen
12/12/11 kirby urner
12/12/11 Dan Christensen
12/13/11 kirby urner
12/13/11 Dan Christensen
12/13/11 kirby urner
12/13/11 Dan Christensen
12/13/11 kirby urner
12/13/11 Joe Niederberger
12/13/11 Dan Christensen
12/13/11 kirby urner
12/13/11 Dan Christensen
12/15/11 Joe Niederberger
12/15/11 kirby urner
12/15/11 Joe Niederberger
12/15/11 kirby urner
12/15/11 Joe Niederberger
12/15/11 kirby urner
12/15/11 Joe Niederberger
12/15/11 kirby urner
12/15/11 Joe Niederberger
12/15/11 kirby urner
12/16/11 Joe Niederberger
12/16/11 kirby urner
12/16/11 Dan Christensen
12/16/11 Joe Niederberger
12/17/11 Joe Niederberger
12/17/11 kirby urner
12/17/11 Dan Christensen
12/18/11 Wayne Bishop
12/18/11 Joe Niederberger
12/18/11 kirby urner
12/23/11 Dan Christensen
12/23/11 Wayne Bishop
12/24/11 Louis Talman
12/23/11 Joe Niederberger
12/23/11 kirby urner
12/23/11 Wayne Bishop
12/24/11 Joe Niederberger
12/24/11 Wayne Bishop
12/24/11 Joe Niederberger
12/24/11 kirby urner
12/24/11 Joe Niederberger
12/24/11 Wayne Bishop
12/24/11 Dan Christensen
12/25/11 Dan Christensen
12/25/11 Dan Christensen
1/13/12 Joe Niederberger
1/13/12 kirby urner