Hi Kristy

Good to hear that the modified octave_function template has been working well for you. I've used a similar template in the first week of my Matlab course to set questions in which I define a few variables and then ask the student to write some code using those variables to print a derived value. Presumably that's how you're using it too?

However, as soon as possible I switch to some variant of the (unmodified) octave_function template, i.e.

{{ STUDENT_ANSWER }} format free {{ TEST.testcode }};

With this template, I ask students to write a **function** to some spec and my test code then calls their function and prints the results. You can see an example of this type of question in my response to your first question in this thread - the *sqr* function. The exported xml for that question was attached to that posting if you want to look at it more closely. [If you're used to Matlab, you may be surprised that this template works, as in Matlab you can't define a function in a file then write global code that calls it. But Octave does not suffer from this restriction.]

Doing things this way round has several advantages:

- It gets students writing functions as soon as possible. While they don't initially really understand functions properly, they don't have any major problems writing ones if you specify exactly what they have to do. They just have to know the syntax for a function declaration. This sets them up much better for later in the course when they're expected to decompose larger scripts or functions into smaller ones by themselves.
- If you explicitly require that the student's function does not produce any output, your test code has complete control over the output from each test. This eliminates the frustration that occurs when students produce output that isn't exactly in the same format as the expected output.
- Your tests can use
*fprintf*to control numeric precision to reduce (but not eliminate) problems with rounding errors. Alternatively, your test code can compute the absolute difference between the expected and the actual results and print 'ok' or 'fail' accordingly. - The environment in which the student's code runs is now completely explicit - the only variables they have available to them are the function parameters and the only result they have to produce is the function's return value. This improves the clarity of the question and also means you don't have to specify in great detail the expected output format. [You
*can*still ask students to write functions that produce output if you like, but then of course you*do*need to specify the expected output carefully.]

*disp*function, written in Octave, that produces output in the same format as Matlab's

*disp*function. My students are using Matlab for their coding but I am testing their code with Octave, so I try to minimise differences. I often test their functions by calling

*disp*to display their answers and if they do the same tests in Matlab before submitting, and see noticeable differences between their output and the expected output, they get worried!

Richard