From Aaron Sloman Wed Nov 9 10:44:41 GMT 2005 To: Alan Dan Achim Mark Subject: Re: SSC1 [Slight edited version of my response to a message sent to me, instead of Achim, by Mark, about how removing mathematics from the SSC1 module will impact on the teaching of graphics, which requires linear algebra.] I was a bit mystified. However I am interested in the educational issues raised: XXX mentioned three options: > 1. Assume all students can handle the linear algebra during the main > lectures and exercises and pick it up in the remedial lectures (you > are still having the extra remedial 1 lecture a week, at least for > the EESE and direct entry students, aren't you?) > > 2. Give a short treatment (and suitable handout) of the most critical > parts of linear algebra to graphics (simple vectors, matrix > multiplication, homogenous coordinates, the standard affine > transformations - don't even go as far as change of bases) and use > the remedial lectures to deal with students who find it difficult. > > 3. Give a thorough treatment of the linear algebra in graphics in the > lectures. > > Personally I would go with option 2: I agree that that's the best of those options, though I suspect only a subset of the list is needed. I have a minority view (inspired by educational ideas of Seymour Papert and John Holt 30 to 40 years ago) that the best way to get *beginners* to understand mathematics is to introduce it in the context of a task they are motivated to do anyway, but without telling them they are being taught mathematics. They can be told that later. So in a graphics course I would let them program some simple graphics and gradually add the kinds of transformations that correspond to concepts from linear algebra. E.g. write a program to draw a line of dots, then show ways of changing the orientation and location of the line. Then replace the code for drawing the line with a procedure that takes a line specification (e.g. a list of numbers) and then draws the line by interpreting the list. Let them consider different ways of specifying a line: e.g. [startx starty endx endy] [startx starty orientation length] [startx endx orientation xintercept] [starty endy orientation yintercept] Note problems about horizontal or vertical lines and problems of ambiguity about orientation. Using a given primitive for drawing a line specified by its endpoints, write a procedure that will draw a polygon given a list of points represented as two element lists [[x1 y1][x2 y2] ...] Investigate a procedure to transform a line specification, e.g. by changing its slope, or intercept, etc. Check the effects by running the program. Investigate how to transform the whole polygon defined by a set of points. etc. Consider different transformations: Vertical [dy] or horizontal [dx] translation is easy. A combined translation defined by a list [dx dy] is also easy. How to add rotation? Consider different ways of representing rotations. E.g. a three element list: [xcentre ycentre angle] Show what has to be done to use the angle to rotate the polygon (repeatedly compute sine and cosine). Consider replacing the angle with a two elemenet list [sine cosine] Try representing combined translation and rotation using a 6 element list or possibly something more structured: [ [dx dy] [[xcentre ycentre] [sine cosine]] ] (Point out that the translation and rotation don't commute. Does that matter?) Then consider how to add an expansion factor (with a centre of expansion). Perhaps discuss generalised shearing (probably will stretch some students too much, so it could be made an optional extra). Discuss features common to all those transformations, e.g. any straight line remains straight, but orientations and distances can change. Consider examples that don't share those features -- eg. rotation or stretching by an amount that decreases with distance from the centre (can produce nice graphical effets). Consider the special case of lines starting at [0 0] and ending anywhere. Introduce unit vectors, and transformations of unit vectors. Talk about how to combine transformations to form a new one, instead of having to first apply one transformation then another. Later show how all this maps into vectors, matrices, etc. The main point is that writing and testing the code to draw and transform pictures will develop the *intuitions* that are absolutely necessary for a proper understanding of the linear algebra (at least in the context of graphical applications). Without pre-formed intuitions it is generally impossible to learn mathematics. It doesn't require graphical programming, but if they are learning graphics anyway then the two combine naturally. If the students are capable of doing the graphics course at all they should be able to understand all this, and work through examples in a nice programming language, using pre-prepared graphical libraries. Then at the end they can be given the mathematical summary of what they have learnt. (I would of course use Pop11, as in this teach file http://www.cs.bham.ac.uk/research/poplog/teach/faces [The graphics stuff starts on line 968] It was originally produced for bright MSc CogSci students who had never done any programming previously, and some of whom knew little or no mathematics. A modified version that does the core of the above stuff with transformations of lines and polygons instead of showing students how to draw sad and smiling faces would probably take a morning to produce. I have been toying with the idea of trying to find time to do something like that. But I guess the students you are discussing will have to use (suffer?) Java! ) I have not looked at the module description, so I apologise if this is all irrelevant! Aaron http://www.cs.bham.ac.uk/~axs/ Last modified: 11 Nov 2005