As most of you know, one the many intellectual puzzles I ponder in my research and professional development work is trying to understand the relationship between the thinking processes highlighted in the computer science literature and the thinking processes used in mathematics — in particular, elementary mathematics.
This morning, a new paper I co-authored with Aman Yadav and Marissa Zhu came out in Journal of Computers in Mathematics and Science Teaching. This paper is the result of some of the examinations I’ve done of how mathematicians versus computer scientists talk about abstraction, specifically. In mathematics, the common narrative is that we should structure instruction around a basic progression from concrete representations and experiences to more abstract representations and experiences. The focus is on the distinction (or sometimes, continuum) between concrete and abstract. The words concrete and abstract aren’t things we ask students to think about in most cases. Rather, they are terms that guide pedagogical decisions or frame research studies (e.g., Agrawal & Morin, 2016; Dubinsky, 2000; Harel & Tall, 1991; Jao, 2013).
In computer science, on the other hand, abstraction isn’t discussed in relation to concreteness. Rather, computer scientists tend to instead draw distinctions between different levels of abstraction (e.g., Armoni, 2013; Hillis, 1998; Wing, 2006). The levels don’t vary in concreteness, per se, but rather in scope and level of detail. At higher levels of abstraction, one can consider a wider scope of a problem, but a courser level of detail. At lower levels of abstraction, one can consider a finer level of detail within a narrower scope. Learning to move among levels of abstraction to change your view of a problem is discussed as an important learning goal for students (Armoni, 2013; Hazzan, 2008).
I was intrigued by this idea of levels of abstraction and the need to change one’s viewpoint of the problem during different points in the problem solving process. Armoni (2013) discussed levels of abstraction in the context of algorithm design. In this new paper, we identified different levels of abstraction students needed to employ and move among in order to solve a commonplace elementary mathematics task. Using these levels as a lens, we examined fourth- and fifth-grade students’ work on the task. It turned out, interestingly but not surprisingly, that many of the errors students made while they solved the task related to challenges in moving among the levels of abstraction. Abstraction difficulties accounted for many more errors than execution of mathematical skills like counting or addition.
In the paper, we argue that this result suggests bringing CS’s explicit attention to levels of abstraction into mathematics instruction could improve students’ mathematics performance. I’m excited to share these findings with our CT4EDU teacher partners and see how they take up the ideas in their classrooms this year.
Agrawal, J., & Morin, L. L. (2016). Evidence-based practices: Applications of the concrete-representational-abstract framework across math concepts for students with mathematics disabilities. Learning Disabilities Research and Practice, 31(1), 34–44.
Armoni, M. (2013). On teaching abstraction in computer science to novices. Journal of Computers in Mathematics and Science Teaching, 32(3), 265– 284.
Dubinsky, E. (2000). Mathematical literacy and abstraction in the 21st century. School Science and Mathematics, 100(6), 289–297.
Harel, G., & Tall, D. (1991). The general, the abstract, and the generic in advanced mathematics. For the Learning of Mathematics, 11(1), 38–42.
Hazzan, O. (2008). Reflections on teaching abstraction and other soft ideas. ACM SIGCSE Bulletin, 40(2), 40–43.
Hillis, W. D. (1998). The pattern on the stone. New York: Basic Books.
Jao, L. (2013). From sailing ships to subtraction symbols: Multiple representations to support abstraction. International Journal for Mathematics Teaching and Learning, September 2013, 15 pages.
Wing, J. M. (2006). Computational thinking. Communications of the ACM, 49(3), 33–35.