In an OutputChallenge, a student matches code with the corresponding output, or matches output with the corresponding code. That is why each OutputChallenge consists of at least 3 pieces of executable code. How to write these, is described in detail in this article.
Here's an example of an OutputChallenge on mobile:
And this is how the same OutputChallenge looks on desktop:
When to use an OutputChallenge?
OutputChallenges are the ideal choice for testing the student's understanding of similar syntax that leads to a different output.
Note that an OutputChallenge cannot generate a plot as an output. To learn about testing plotting knowledge, go to this article.
Authoring an OutputChallenge
The anatomy of coding Practice exercises, such as OutputChallenges, is described in this article. This section here describes the specific syntax to write an OutputChallenge in the Teach editor.
To learn about using DataCamp's Teach editor to create practice content, take a look at this article.
The OutputChallenge template contains an optional context block. When and how to use the context block is described in the article on Practice exercise anatomy.
At the bottom of the OutputChallenge template you'll find the pre-challenge code block. You'll use this block to prepare the workspace, allowing the exercise code to run properly. So this is the place to be for loading packages and datasets or creating datasets on the fly.
Exercise code and variables
A code block provides a placeholder to generate code for an OutputChallenge. That makes sense, right? By including references to variables specified in the variables block, you create variations on the code. In the Teach editor, variables are referred to by placing the variable name between double curly brackets:
For example, the code below refers to variables
fun1 . As such, the different options for this exercise are dynamically generated based on the values specified in the variables block.
The OutputChallenge template contains multiple code blocks.
You can use additional code blocks to specify several code templates. In this case, for the generation of each option, the backend will first randomly select one of the two templates, and next randomly fill it in based on the provided options for the variables. It's therefore perfectly possible that 2 out of three generated options come from the first template, while the third one comes from the second template.
To limit the variability between the different options that are generated, it's possible to anchor certain variables. Have a look at this example:
$, we are slightly changing the way the 3 code-to-output or output-to-code options are generated. Instead of randomly selecting a value for
fun1 for each option, a value for
var2 will only be chosen once. All the options that are generated will now use the same combination of
var2 , and only
fun1 will be varied for the different options.
This will typically be useful if you're working with data variables, and you don't want the different options to contain very different dummy data to start from. With anchoring, you prevent the options from being too different, but there's still a high degree of randomization, because the anchored variables are still randomly chosen in the first stage.
Now that you've seen the details of creating an OutputChallenge, take another look at the examples provided at the beginning of this document. Do you see how they relate to the code mentioned throughout the document? Can you tell whether anchoring has been used?
Now it's your turn! Go to the Practice pool you are working on and make some amazing OutputChallenges!