English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
Re: Re: Teaching bottomline, part 3: what should improve.
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2007-05-23 (17:10)
From: Pal-Kristian Engstad <pal_engstad@n...>
Subject: Re: [Caml-list] Re: Re: Teaching bottomline, part 3: what should improve.
Vincent Aravantinos wrote:
> Those are typically the comments of a "used-to-functional-programming" 
> guy.
> It certainly doesn't match what a beginner would think (no beginner 
> will call a
> function a "value").
This reminds me of a "game" I used to teach my math students the concept 
of a function. I think it should be able to be used for an introductory 
computer science class as well.

Essentially, the game involves having person A come up with a rule. 
Person B will have to provide an input value, and A has to faithfully 
give the result of the rule/computation. Examples of functions could be 
\x->x+2, \x->2*x, etc. More interesting examples involves the function 
that returns the first letter of the name of the input (f "one" = "o"), 
or the successor of a "red, yellow, green" traffic light symbol.

When doing this, A and B will quickly have to agree on the allowed input 
values (the domain) and in order to have a chance it is also helpful if 
B knows the range of output values (the image). And for sure - they will 
have to agree that the rule x = y => f(x) = f(y) has to hold in order to 
be able to guess what "f" is. [I would also disallow closures for this 
game - otherwise it would be too hard to guess.]

The reason this exercise is good is that it teaches the students (in a 
fun way) the important concepts behind a function. It will make them 
understand that a function is just a computation, but also point out the 
importance of defining the types (sets) of inputs and outputs. I think 
that after playing this game, you can venture to talk about the "name" 
of the function, and they will realize that it does not matter what the 
name of the function is - just what it does.

Perhaps after this, you can teach the concept of treating a function as 
a value, or input to another function? Person A makes a function that 
takes person B's function, etc.



Pål-Kristian Engstad (engstad@naughtydog.com), Lead Graphics & Engine Programmer,  
"Uncharted"-team, Naughty Dog, Inc., 1601 Cloverfield Blvd, 6000 North,
Santa Monica, CA 90404, USA. Ph.: (310) 633-9112.

"Most of us would do well to remember that there is a reason Carmack
is Carmack, and we are not Carmack.",
                       Jonathan Blow, 2/1/2006, GD Algo Mailing List