[Edu-sig] re: Checking an assumption

[Arthur]

Laura writes -

>Assumption one sets you clearly on the path of _education_ rather than
>_training_.  (Training is pretty much all about repetitive action.)
>When _educating_ works, you need students who are able to memorize new
>chunks of abstract knowledge, and then know exactly where to store and
>apply it in the knowledge structures which they have in their own
>brains.  This will only happen if your students already have a nice
>collection of mathematical knowledge, and enough mathematical
>intuition to know how and where to add new stuff.

We all have our themes. And, it often seems to me, that our differences tend
to be more about how we use language, than in the substance. 

"Training", as repetitive action, one of your themes. 

I suspect I must misunderstand what you mean.

For example:

My ability to memorize is weak. Plagues me. My ability to absorb abstract
ideas decent.  There are many concepts I've absorbed, which when I confront
again, I understand in broad brush, but find I have lost the details. But
the details are usually easy to retrieve. The concepts, if truly absorbed,
become the basis of intuition. Which is the most important thing to develop,
in most fields, it seems to me. Yes, repetition is admittedly part of that
process.  But I am not sure to what extent it is to its essence.

>I assume that your students will be older than this.  Indeed, I assume
>that they either a) already know how to program, or b) the statistics
>that you wish to teach them are the sort that you can do in a trivial
>amount of Python code -- the sort of thing that you can just type into
>a Python interpreter.  If you don't have this sort of match, then
>what you will end up doing is teaching your students how to program.

PyGeo has lead me to actually lecture in front of a few math faculty groups.
It actually blew my mind that the whole subject of programming was a blank
slate to many of them.  It was partly, at least, generational. Which makes
sense.  I can't believe that a new generation of mathematicians would not
have a programming toolchest as a given.  

One of *my* themes.

>What is important is to get the ability to visualise data.  And to learn
>that, you have to draw it.  Learning how to read graphs is not enough, and
>learning how to write a computer program that draws graphs is also not
>enough. You actually have to make a bunch of drawings, again and again and
>again before, given a series, or an equation, you can actually have a
>geometrical sense of what is going on.  (And some people never get it,
>no matter what you do.  It is quite frustrating.)  Check and make sure
>that this is not what really is supposed to be taught in that class
>before you replace the pen and pencil with Python, because in that
>case your assumption 1 is shot, and you are supposed to be training
>them.

Some fundamental agreement.  Most of the "dynamic geometry" applications
commonly used in schools today - and, as it now stands, one of the few
common K-12 uses of the computer in the mathematics classroom - can be quite
destructive.  Computers can be quite destructive. Doing by mouse clicks
exactly what should be being done by compass and straight edge. Much, much
is lost. Those same software tools, used with sparing intelligence - I am
sure, can be a good plus. So it not the tools themselves, in isolation,
which is the issue. 

I don't want PyGeo being used for teaching fundamental plane geometry - even
though by insisting on script rather than encouraging mouse clicks - it is a
step in the right direction.

Flipside - I have built a tool that allows me to extend my imagination
beyond its normal limitations, to visualize more advanced concepts than
would otherwise be accessible to me by manual drawing of any kind. PyGeo was
built exactly from that need, to allow me to see the kinds of things that
others with more powerful visual imaginations might be able to see purely as
imagination.

Quite exciting, at times.

And there is nothing quite like it out there, as far as I am aware.  So yes
I am proud, and yes I do go on about it.

>Which is what I do all the time, and is the reason why I
>always have to look them up.  I never actually _know_ them.

What is wrong with having to look them up.  If you know where to find them,
you know them - for all useful purposes.

>This is a really useful and valuable skill, but probably not what you are
>trying to teach.

Why shouldn't it be?

>This problem can work in the other direction as well.  For instance,
>you will have to give them a nice lecture on 'What is Floating Point,
>When can you use it, and when must you never use it.'I'd dearly
>love that lesson taught to high school students, world wide.  But
>it is tough going, and my gut feeling is that it will not be easy
>to teach this one until your students have an extremely good sense
>of what experimental error is.  If they don't have that background,
>then they may confuse floating point error with experimental error
>which is a particularly nasty misconception to uproot later.    

Some folks have felt that physics students at major universities need to be
protected from the concept.  Arghhh, I say. Aren't we at least a bit about
being a vanguard here? Speaking up and out on this kind of thing. 

Yes it is tough going. 

>Also, when building a computer program to do some sort of problem in
>numerical analysis, you may find that the bulk of the program is spent
>doing corner cases and handling particularly nasty sorts of data.

Damn divide by zero.  Luckily for me, in what I happen to be studying, the
corner cases are to the essence. So I resent dealing with them less. The
straight line, *augmented by the point at infinity*, etc. But yes, you are
right.  Much focus ends up on dealing with the corner cases, when using a
programming approach.  A negative, I could see, in many circumstances.


>Writing this code -- at least the way I do it -- is a matter of
>writing a bunch of unit tests and building the code so that it handles
>all the perverse cases.  But first, your students may be too naive to
>see the perverse cases -- this is where they are being first exposed
>to them, after all, and second, in a basic statistics class, you may
>want the students to focus on how things go when your data is
>well-behaved, and doesn't provide any problem for the programmer.  So
>there the goals of test-driven design and learning the statistical
>methods may work at cross-purposes.

I don't know much about statistics.  But would think that the perverse case
is also to its essence.  Or more to its essence than a student might
otherwise commonly have reason to understand.  

>But, provided these problems do not raise their ugly heads, it looks
>like a lot of fun, and could be the sort of class where you actually
>get a taste of 'what life has to offer' rather than 'what school has
>to offer'.  Sounds good to me.

Getting the school out of school - within reason, is great. Too much in that
direction OTOH. Which is what you are also saying, as I am interpreting it.

Getting middle-aged and seeing and appreciating the middle ground more and
more... Well its sure hard to get anyone's attention by advocating the
middle ground. 

What, no new paradigm?

The old paradigm and the new paradigm - each done right - would look
remarkably similar, IMO.

Art