Brian van den Broek: > I'd agree with you if experience hadn't taught me otherwise. I do see > the CS and math notions of functions are tightly related (with the > difference that math functions don't have side effects).
However, I think mathematicians should accept the CS "side effects" as just more of the function's result, wherever and however it shows up. One thing I like about computer programming is it quickly gets you into operating with inputs/outputs other than numbers, strings for example. The early math exposure kids get is too exclusively number-focused IMO. Books like 'Godel Escher Bach' are a good antidote. My suggestion that a factory machine which twists lids onto milk bottles or the like, is a good model of a function, would be designed to break this fixation on numbers, always numbers. In a hybrid techie-math class, we'd wire sensors to chips, so that inputs were things like temperature, outputs various GUI gizmos -- more like the cockpit of an airplane (instrumentation readings = output, environmental conditions, like altitude, wind speed = input). The mathematicians' *notation* 'f : x -> y' or whatever they use, may well be about turtles moving, toasters popping, cranes swiveling, cells dividing. The abstraction is about taking inputs to outputs, stimuli to responses, causes to effects or whatever. In the case of random.randint(5), it needs to be explained that just as outputs may be other than what's explicitly returned (so-called side-effects), inputs may be coming from places other than the argument list -- in this case, there's a sequence of pseudo-random numbers being computed algorithmically, with state saved between calls (like in a generator). I think lots of examples of simple causes -> effects drawn from ordinary life helps phase in the new function semantics in a way that's very glued to everyday experience. In the case of propositional calculus in particular, I favor using logic gates at some point in the discussion. Little diagrams of AND OR NAND NOR XOR. http://encyclozine.com/Connective You can use these to assemble the behavior of p->q i.e. p,q are inputs to a logic gate setup, and the value of p->q is the output. p q p->q T T T T F F F T T F F T In Python, you can use Booleans, e.g. the above is equivalent to >>> def ifthen(p,q): return (not p) or q i.e. (~p | q) <-> (p -> q) >>> combos = ((True,True),(True,False),(False,True),(False,False)) >>> for p,q in combos: print "Inputs: %s\t%s\tOutput: %s" % (p, q, ifthen(p,q) ) Inputs: True True Output: True Inputs: True False Output: False Inputs: False True Output: True Inputs: False False Output: True Kirby _______________________________________________ Edu-sig mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/edu-sig
