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