Posts
The problem is that educators know very little math. They don't know how it's used in real life.
One of my specialties is curved surfaces for geometric modeling. I write software for shape design and analysis. I once had to write a routine that would find the intersection of two tensor product polynomial surfaces. This has to be done algorithmically, and there are lots of methods given in the literature. It would be stupid to ignore those solutions just to discover my own. I'm not proud. I'm more than willing to copy what someone else has done, so I studied the literature. In fact, if you write a technical journal article, you better show that you have a full grasp of and reference to all other key articles and books. If you ignore the literature and (re)discover a technique, then it either won't get published or it will get trashed by your colleagues. Ignorance is not treated lightly. Prior art reigns supreme. (knowledge and skills)
However, nobody had a solution that met my need for speed of calculation. I had to create my own solution, but I don't start from scratch, and I don't use some sort of pattern recognition or critical thinking to find a solution. I use my toolbox of mastered skills. First, I have a fast way to convert each polynomial surface into a large set of triangles. All I needed next was to find a very fast way to determine if any two triangles intersect. I don't "discover" a solution. I look at the problem and see how my toolbox of mastered (rote) skills can be applied; vectors, dot products, cross products, parametric equations, different forms for defining plane equations, and matrices.
These skills don't exist in some sort of rote or out-of-context space. They have a meaning and a use. Two independent vectors define a plane. If I take the cross product of the two vectors, I have a new vector that is perpendicular to that plane. I didn't discover that. I was taught that.
Don't educators understand that being creative mathematically requires a whole lot of basic, mastered skills? The larger your tookbox of mastered math skills, the more creative you will be.
I don't know why they have this rote or script hangup. They just don't have enough understanding of math to know if anything they do is correct or incorrect.
Subscribe to:
Post Comments (Atom)
8 comments:
It's really no different then art. To create a truly creative drawing you've got to have tools, understand how they work and have some skill in using them. Otherwise it's just scribbling.
Maybe educators today just like scribbles?
I was going to make this a separate post (still will, I guess, but it's basically the refined version of what you said here, Steve.
Here's an outline of Poly's book How to Solve It, the greatest book on teaching math students how to solve math problems ever written:
http://www.math.utah.edu/~pa/math/polya.html
notice when it comes to solving the problem how he references the toolbox, how many times/ways/shapes he tries to get a student to think in terms of what HE ALREADY KNOWS HOW TO SOLVE.
(the book is worth reading even after reading the summary. the book uses real examples of problems students needed to learn to decompose into solvable pieces.)
but here's the beginning of the summary:
UNDERSTANDING THE PROBLEM
First. You have to understand the problem.
What is the unknown? What are the data? What is the condition?
Is it possible to satisfy the condition? Is the condition sufficient to determine the unknown? Or is it insufficient? Or redundant? Or contradictory?
Draw a figure. Introduce suitable notation.
Separate the various parts of the condition. Can you write them down?
DEVISING A PLAN
Second. Find the connection between the data and the unknown. You may be obliged to consider auxiliary problems if an immediate connection cannot be found. You should obtain eventually a plan of the solution.
Have you seen it before? Or have you seen the same problem in a slightly different form?
Do you know a related problem? Do you know a theorem that could be useful?
Look at the unknown! And try to think of a familiar problem having the same or a similar unknown.
Here is a problem related to yours and solved before. Could you use it? Could you use its result? Could you use its method? Should you introduce some auxiliary element in order to make its use possible?
Could you restate the problem? Could you restate it still differently? Go back to definitions.
If you cannot solve the proposed problem try to solve first some related problem. Could you imagine a more accessible related problem? A more general problem? A more special problem? An analogous problem? Could you solve a part of the problem?
There is also the big field of systems analysis, which defines very formal methods for solving complex problems. Although it's generally for software development, the techniques can be applied to other areas. I taught a course in this for several years, but I can't say that I'm a big fan of many techniques. If I never see another data flow diagram or have to do a code walkthrough again, I'll be quite happy.
I'm a big fan of prototyping and something I call outside-in software development. You do a partial analysis from the top down, but much of the coding (outside of a basic framework) is done from the bottom up.
The key ingredient is that you can't know all of the problems of a complex system before you actually work on the project. Analysis and design tools might help, but they quickly fall apart with the details.
The advantage of a prototype system is that you can get started coding right away. That is a big psychological boost. Also, integration and testing is done on the fly and not some sort of horrific event near the project deadline. Small changes can be added and tested much more easily than trying to identify and fix scores of problems with a traditional process.
The risk of prototyping is that you are making a major mistake and don't know it. Generally, this isn't the case unless you don't do any preliminary analysis. However, the advantages of doing more top-down preliminary analysis and design before coding fades very quickly. That's because the unknowns and risks increase to make that work almost worthless. The best analysis and design is to actually write the software.
I find this a very fascinating area. The classic work is "The Mythical Man-Month". There is nothing like having just a few, really good programmers to accomplish amazing things. It's not so much the systems analysis approach, it's the content, skills, and experience of the people.
Process can never replace these things.
Two independent vectors define a plane. If I take the cross product of the two vectors, I have a new vector that is perpendicular to that plane. I didn't discover that. I was taught that.
Absolutely. I mean really, I wish advocates of discovery math would step back for a minute and think: gosh, how much time would it actually take to discover each of these incremental stepping stones of algebra and geometry? How much can the kids possibly learn under that paradigm? Not a whole heckuva lot.
I always start coding bottom up. For me, it was definitely about confidence building: look! I've built the selectors! It was a big psychological boost to know that the tiny functions I wrote were right and real. See, I've got a function! it works! I can give it inputs right now!
My husband taught me to do something even more wonderful: write the tests first. You really want to figure out how to know if your complex system is gonna do what you want? Start by writing tests your complex system needs to pass. Some are unit tests that validate the inputs or outputs or perform simple functions. But bigger tests work too. If you can actually define knowing what "success" looks like, you have a heck of a lot better chance of designing a system that meets it. Because all the design in the world isn't going to help you actually validate what the complex system does when you wire it all together. And if you force yourself to actually define success by writing the tests in the first place, then you know what you really want better than most analyses show you anyway.
He's a big proponent of "disposable code". You know how everyone was into reusable code for a while? His point was that it was hogwash--code is a liability, not an asset! Be willing to jettison old ideas, old designs, old objects whenever! All you do by believing in reusable code is trick yourself into believing you've prototyped things already, instead of just *doing* it and seeing what you get.
Systems engineering as a discipline is another place where the theory and formalism fail you unless you actually know SOMETHING about SOMETHING. IE/OR or process engineering etc. is really meaningless until you've been doing engineering for a while, and have a feel for how the process really works. Try as engineering companies might to make their processes idiot-proof, domain knowledge DOES matter, and only those who really have domain knowledge can understand how to subordinate process to things.
Problem solving in math class is similar. Another reason you can't really solve a math problem by "discovery" is because how would you validate or verify you got the right answer? You have to have some extreme values, some edge cases, something where you KNOW what the answer should be, and see if you work validates to that.
"...code is a liability, not an asset..."
I have two types of code; the specialized code that solves a problem, and my libraries of tools. Whenever I code, I'm on the lookout for functions that are generic in nature. Of course I have libraries of vector, matrix, and geometry routines, but I also have other routines for doing things like non-linear searches. So, if I have to solve a function, I can write a stub of a program, use the library routine, and completely test it out before integrating it into the main program. I can easily throw away or alter my main code since I have my huge toolkit of libary routines to regenerate new code quickly. That's why I'm big on prototyping. Coding is not an expense that needs to be minimized. It is an opportunity for major improvements.
"Try as engineering companies might to make their processes idiot-proof, domain knowledge DOES matter, and only those who really have domain knowledge can understand how to subordinate process to things."
Exactly. You don't hear a lot about CASE (computer-aided software engineering) anymore. I was really into Warnier/Orr diagrams many, many years ago, but realized that although the idea was great in general, a strict following of the process was not going to get the job done. Output requirements change. Although going backwards forces you to solve a real problem, you might not know yet what the real problem is.
But isn't this what educators want too; no strict adherence to a rote system of steps where the student expects to turn the crank and get the right answer?
So, what's missing with their approach? There is nothing to back it up.
There is no content knowledge, skills, and practice. Educators don't like rigid algorithms or processes, but they only replace it with a vague thinking process. They are mixing up the tools with the product.
Educators don't like the idea of invert and multiply for dividing fractions, but the problem is not the lack of some sort of understanding, the problem is that the students didn't practice it enough to apply it flexibly and accurately to all situations. The goal is not to work around skills, but to master them.
You know, this post (and the subsequent comments) would tick me off a lot less if every use of the word "educators" was preceded by the use of the word "some".
Seriously, guys. I work in the ed business, with both mathematicians and math educators, and very few of them resemble your caricature.
"...tick me off a lot less ..."
But it would still tick you off. Most people here understand that it's not "all educators", but I would strenuously object to your use of "very few".
Why don't you just try to explain what your left over tick off is all about. The comments made in these threads don't come from out of the blue. They are not about bashing. They try to figure out what is going on.
"I work in the ed business, with both mathematicians and math educators, and very few of them resemble your caricature."
And what, exactly is your view that you think we are missing, for both educators and mathematicians? This is not a snarky comment. I really want to know if I am missing something.
Post a Comment