On Sat, Aug 2, 2014 at 10:35 PM, Robert Hansen <email@example.com> wrote:
> > On Aug 1, 2014, at 8:23 PM, kirby urner <kirby.urner@GMAIL.COM> wrote: > > > Robert Hansen and I reached a truce awhile back (for discussion > purposes) that we wouldn't start looking at coding until around the time we > introduce Algebra. > > Actually, my stance is that learning to program isn?t a substitute for > learning mathematics. I don?t care when you start programming activities, > but you aren?t going to become mathematical in your reasoning unless you > explicitly study mathematics. And many programming tasks require explicit > mathematical reasoning behind the scenes, at least explicit algebraic > reasoning. Some tasks, like writing SQL require extraordinary amounts of > mathematical reasoning. Tasks like writing HTML might not at first, but > writing dynamic HTML (Web 2.0) do. Obviously, anything involving numerical > analysis requires extraordinary mathematical reasoning. My take on our > truce is that you can?t really develop the potential of programming until > you've progressed (successfully) through algebra, regardless of when you > started programming. > > Bob Hansen
That sounds like my position pretty much. I'm mainly focusing on the curriculum from Algebra onward, we could say, when programming kicks in as a live proposition, a worthwhile mathematical activity. All the basics should have been mastered by then.
Now that we're on the far side of Algebra, we're ready to start up with SQL (getting our feet wet, not talking about exhaustive training) and the different mathematical notations that happen to be machine executable i.e. the so-called "programming languages" (e.g. the J language from jsoftware.com)
We'll continue with trig, coordinate systems, vectors, polyhedrons, polynomials etc. etc. but with programming as one of our common core activities. I've provided a tentative outline (incomplete) in another thread:
I. Data Storage and Manipulation
(r) weights and measures (dimensional analysis) (t) Muti-dimensional arrays (numpy)
II. Concept of Function (with sets, injective / bijective / surjective):
(k) Trignonometric functions (l) Logarithmic functions (m) numbers and bases (h) Linear Equations (i) Polynomial Equations (see "NCLB Polynomial") (v) binomial theorem (Newton) (w) Pascal's Triangle / Tetrahedron (j) rates of change (pre-calc discussions)
III. Visualizations / Graphs / Networks (polyhedrons are also networks):
(f) XYZ coordinate system (in context) (g) Vectors as Objects in an OO computer language (x) Turtle / Tractor Math (Tractor stuff optional) (a) V + F = E + 2 (Euler's Law) (b) Descartes Deficit (720 degrees = 1 tetrahedron of angle) (s) Matrices (rotational especially) (u) concentric hierarchy of polyhedrons
IV. Number and Group Theory
(p) prime versus composite (Fermat's Little Theorem) (q) totatives and totient (Euler's Theorem used in RSA) (c) Euclid's Method for the GCD (a Python program) (d) Fibonacci Numbers (e) Figurate and Polyhedral Numbers (1, 12, 42, 92...) (n) permutations and combinations (o) group, ring and field properties (y) Fractals (z) Cellular Automata
Algebra itself is covered in many different ways, and those going on in a more digital vein, as distinct from the paper and pencil analog math of yore, would benefit from an Algebra that's more CS-friendly.
I've been giving concrete specifications as to what that means e.g. if all your examples of functions are numeric, then that's closing doors and closing minds and we should shy away from such time-wasting textbooks (if planning to go on in the direction I'm suggesting).
Programming opens the door to mathematically-based art, such as fractals. In taking the tedium out of repetitive computations, we're able to rotate colorful polyhedrons on screen using code we've written ourselves.
That feeling of accomplishment that comes with controlling hardware / devices, including robots of various kinds, is positive reinforcement and confidence-building.
A little object oriented thinking goes a long way when introducing "math objects" such as fractions, vectors, complex numbers, polynomials -- all represented as "types of object" in an OO language.
I'm not saying we have to stick to object oriented languages, but I don't go along with your notion that we need a language "like Python but without the objects". Python is "math student ready" exactly as it is, right out of the box.