This was originally posted on Grok Learning’s blog – a site worth visiting!
This time, I’d like to dive deeper into introducing algorithms as a product of computational thinking which may not necessarily lead into coding. In particular, I want to go into concepts involved with algorithms, and not just the mechanics of CT. Click back on links above to see some of my previous algorithms for introducing algorithms. These CT models via Conrad Wolfram and Grok Learning (printable PDF) are valuable resources as well.
When I was planning how to introduce algorithms to my 10 Information and Software Technology class, I listed concepts relevant to algorithms as essential learning. I wanted students to engage in active learning and, by deduction, realise that these are indeed essential aspects of algorithms.
- Representation/notation — how to encode the algorithm
- Granularity — level of detail of instructions
- Accuracy — correctness of the algorithm, does it solve the problem correctly?
- Efficiency — does the algorithm save /waste time and effort
- Interpretation — is it ambiguous or open to interpretation?
I could add more, such as scalability, variability and bias, but decided not to, at this stage.
I started by asking the students if they knew what algorithm meant knowing most if not all would have heard the term, quite likely in maths. True enough, we came down to ‘a set of instructions designed to achieve a task or solve a problem’.
I got everyone to count off 1 to 4 and based on their number would do one of the following:
- Draw the steps for making toast
- Draw movements for a favourite dance step/sequence
- Write how to get from the classroom to the train station
- Write how to perform ‘Happy birthday’ in instrument of choice
This was a no-talking activity. If they were drawing, they couldn’t use words and if they were writing, they couldn’t use symbols or drawing.
Those doing #3 took the longest but after about 15 minutes, I got everyone to move and look at another student’s work. I also asked those who were viewing #2 to attempt to do the dance sequence.
Ensuing class discussion raised some interesting points:
- One student quoted “using your legs, walk to the door…” which raised the issue of granularity
- When asked whether his dance sequence was interpreted correctly, the response of “open to interpretation” raised the issue of ambiguity and ‘limitations’ of interpreters
- “Is that even a slice of bread?” raised the representation aspect
- Representation and accuracy were problematic for the song and the student resorted to musical notation although admittedly unsure that the notes are in fact accurate
- Another students toast’s drawing with power setting set to maximum raised the question of efficiency — possibly saves time but risks waste
The activity allowed students to see the challenges involved when designing algorithms; and, we had the language to talk about it.
I started the next lesson by getting 2 volunteers. The first one had to add 25 and 12 (2-digit addition with no carry). The next student had to add 275 and 38 (with carry). The plan was to focus on the process of abstraction for a fairly well-known algorithm and introduce various control structures.
We talked about the term ‘abstraction’ (pick out essence, general patterns) as we discussed the algorithm for solving each of the problems above. Much merriment ensued as the students struggled to articulate the steps, especially as they could not remember the term ‘place value’ (ha!). Once we got the first sequence right, the second one presented the opportunity to introduce selection control structure, i.e. if the sum exceeded 10 and there is a carry.
From here, it was not too much of a stretch to introduce the concept of repetition control structure. So, students were then challenged to abstract further and re-write our selection-sequence algorithm to handle addition of multiple digits and numbers. Those who’ve done IST previously and familiar with pseudocode, got straight into representation without worrying about ‘How do I say this?’ that the others struggled with. And thus, I no longer had to justify why they needed to learn the key words.
“Your algorithm is different from mine.” How wonderful to hear that!
On the third lesson, the focus was on ensuring the algorithm is correct. I taught them how to desk-check, a manual process of checking algorithm logic . I premised it on this was just like their table of values when doing Algebra — and that in fact, designing algorithms is like finding the equations given a table of values. A majority of my class like maths so this was a safe bet.
We are currently on deliberate practice, necessary to develop most new skills. A quick web search generated plenty of sites giving me a range of problems varying in terms of difficulty, complexity, context/interest. Grok Learning also has heaps.
Maybe I should ask them to dance the algorithms…
I’m really happy with how this turned out for me. I think the students have a deeper understanding of algorithm design plus they have the vocabulary to articulate this understanding. There’s more to learn but I believe the foundation is sound.
Please share your algorithm or perhaps thoughts on how mine could improve.