On Mon, Dec 12, 2011 at 10:48 PM, Dan Christensen <email@example.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:
- -- 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).