Message Boards Message Boards


Implement computer-based math (CBM) first at beginning or advanced classes?

Posted 6 years ago
4 Replies
17 Total Likes

Assume we wish to ultimately restructure all K-12 and college mathematics courses to be computer-based math, to the extent possible.

Would the most effective approach to such long-term adoption of computer-based math curricula be to

  1. start with elementary courses for young children and gradually expand to ever-more advanced and sophisticated classes for older students, or instead

  2. start with advanced classes for older students and gradually expand to ever-more elementary and basic classes?

There seem to be good reasons for each of these tactics. Which would be most effective?

Now that several responses have appeared, let me voice my view on my question.

Indeed, both approaches have their strengths and weaknesses, but I overall I favor starting with "senior" or advanced courses and then moving towards earlier classes. Why? One of the key insights and motivations for computer-based math curricula is the importance of expressing a problem, such as a real-world problem, into the language of mathematics and only then turning the crank of computer-based calculation. Older students will have a body of facts and knowledge from real-world disciplines such as physics, biology, chemistry and possibly even economics and business. This will allow them to concentrate on the asking of sophisticated questions and casting such questions into mathematical form. I think it would be more difficult to teach to young student both the real-world content and the techniques of expressing problems in mathematical form. Moreover, advanced students are more likely to have developed some expertise in programming, thereby avoiding some of the educational burden in the mechanics and basic concepts of computation (recursion, iteration, ...). I imagine that the pedagogical "lessons learned" from computer-based math at senior levels would expand and become incorporated to earlier classes over the course of several years.

These are just my current views. I would be quite open to changing them in light of carefully constructed educational experiments.

4 Replies
Posted 6 years ago

I'm a foot soldier in education, a veteran public high school teacher, mostly for inner-city kids. On paper I have been teaching English and Math, but whenever I can I teach programming. My students always had a goal and programming was part of reaching that goal. Often the goal is to make educational video games because it catches most students' interest and, hey, that's the way I roll. I find that some curricula that set out to "teach programming" treat programming as the end, rather than a way to realize a concept. The end shouldn't be some arbitrary assigned product, like a digital rolodex or an inventory reporting app; it should be something that the students really see value in.

The trend today is to start beginners with shallow but easily learned "languages" like Scratch, Game Maker, or Lego Mindstorm. My observation is that students need deeper languages than these, real full-fledged languages that can take the students where their imaginations go.

To answer the question, I would favor starting with young students, perhaps in middle school, on projects that have meaning to them. Once the students start to feel the power that programming brings, they will thirst for more. A deep, rich programming language like Wolfram can take them as far as they wish to go. This would drive the need for more advanced classes.

Mark, how do you see the Wolfram Programming Lab fit in with your vision of projects that have meaning to young students?

To David's question, it would seem like both strategies could work. Maybe the latter would be more stable, more cautious. By starting out with courses for older students, they have a larger knowledgebase about the world and it is easier to imagine that they could do more meaningful projects. You get a more tangible success to build upon than you might by starting with younger students. Effectively you are starting small and simple, where there is already a large amount of developed material. On the other hand, I've seen amazing things from younger programmers too.

Posted 6 years ago

A team of my high school students made a video game about the Lewis & Clark expedition. One part of the interface required arrows to hit a bulls-eye, distance from the center depending on how accurately the player answered numerical questions. The students wanted the arrows to be spread randomly about the circular area. One student worked out a scheme using the Pythagorean Theorem which took roughly 100 lines of code in the Transcript language. Another student did some research about trigonometry and came up with a more elegant solution that took about half the code. From what I've experienced so far in Wolfram Language, positioning the arrows would have taken five lines of code or less. That leaves more time for the students to solve problems and less time writing and debugging code.

Another game had the players banking a virtual laser off a mirror and through a refractive medium. One ambitious student built a circular chess game. Another distorted the colors of paintings so players could get used to identifying different color schemes. A team of students was stymied when they tried to make a game on taxonomy because the data set would have to be too massive. Yet another project that was loosely modeled on Magic the Gathering, a game in the same general genre as Dungeons & Dragons, had cards that featured artists, musicians, scientists, historical figures, etc. along with associated artifacts. Though the students finished that game successfully, it was limited by the size of the underlying database, the structure of the data, and how the data was accessed and processed.

These are just a few examples from over a hundred that the students, with a bit of guidance, produced. I think that every one of them would have been better if the students were using Wolfram Language. Why? Because classroom time is limited, so a succinct language like WL allows the students to get more done in less time. Their time with the language would have been spent learning about what functions do, what happens when you nest them, etc. instead of trying to hunt down the scope of a variable or figure out some arcane syntax. Many of the games, like the taxonomy game or the game involving refractive media, would have benefited from access to curated data. I think that the students would learn more about programming, about math, about the academic subjects that the games are based on.

If I were to use WL in the classroom, that is how I envision it. Having done it with cruder resources, I know that the approach works.

(Sorry for the longwindedness. I'm an English teacher too.)

There is certainly something to be said for both approaches and the reality is probably that the truth lies in the middle somewhere. Here are some ideas I found myself going through after reading the original question:

First of all, I think that from a practical point of view there is one big advantage in the safety of starting with older students. Throughout their education, students learn to learn and because of this older students are less likely to be negatively affected by start-up problems in the materials. Another plus is that if you manage to impress older students, you might benefit from their enthusiasm quickly and build up momentum (e.g., they might turn out as teachers that advocate WL).

Conversely, if you decide to start off by focusing on younger children, you're taking up quite a large responsibility. Furthermore, If you can't keep up with the development of materials for progressively older students, you're risking that their interaction with Wolfram Language becomes an isolated incident in their childhood. Then again, if you get it right and manage to get good results with a younger audience, it would take an extreme amount of skepticism to argue against CBM.

Reply to this discussion
Community posts can be styled and formatted using the Markdown syntax.
Reply Preview
or Discard

Group Abstract Group Abstract