RE: [Aimmath-developers] Multipart questions ... a little trap

[Ken M. <mo...@pt...>]

> -----Original Message-----
> From: aim...@li...
> [mailto:aim...@li...]On Behalf Of
> Gustav W Delius
> Sent: Tuesday, September 02, 2003 4:48 AM
> To: AIM developers
> Subject: RE: [Aimmath-developers] Multipart questions ... a little trap
>
> I am strongly in favour of imposing the requirement on the
> student to answer
> the parts of a multi-part question in the correct order. I would
> be happy to
> have this requirement on all multi-part questions. I do not quite see the
> need for multi-part questions that can be answered in any order. Even in
> those cases where it would make sense to answer them in any order, what is
> wrong with following the given order? So I think the AiM code should be
> changed. Writing AiM questions is complicated enough as it is,
> having to put
> in extra checks into the question code is not desirable.
>
> What do others think?

I agree with Greg and Chris... we should not impose this requirement.  How
the answers of the various parts depend on each  can be very complicated and
should be decided on a question-by-question basis by the question author. I
think it would be much too inflexible the other way.

We might eventually develop some tools to assist authors with the dependency
checking along the lines of the depends> flag Greg suggested, but before we
do that we probably should think carefully about what "depends" means.  Do
they have to have simply attempted the prerequisite question? Or do they
have to get it correct?  What if we want to assign partial credit to their
second answer if it is correct GIVEN their incorrect first answer? Hmmm.

For example, even with Greg's modification to Neil's original question, what
if the student enters, say, 10 for the first part and 41 for the second
part, marks the quiz, and then goes back to the first part and changes the
10 to 41 so that both questions have 41 for an answer?  They get 1.9 out of
2.0 possible points even though they have only given one prime bigger than
lowerbound.  To avoid this we might want to change the question even further
so that the first answer has to be correct before credit will be given in
the second part, i.e. change:

   if not type(p1, posint) then
    # Make sure the student did in fact answer the first part!!
    `aim/t`("You haven't answered the first part yet!");
    RETURN(0);

to something like:

   if not type(p1, posint) or not p1>lowerbound or not isprime(p1) then
    # Make sure the student did the first part correctly!!
    `aim/t`("You must answer the first part correctly before you can answer
this!");
    RETURN(0);

But now in this situation we can have a scenario that is stranger still!  If
the student enters 10 and 43 for the two answers, then marks the quiz, then
changes the first answer to 41, the student gets no credit the first time
around, but when marking it the second time both parts of the question say
"Your answer is correct", yet the total score is only 1.0 out of 2.0,
because (I think) the answer to the second part of the question didn't
change, so it wasn't regraded!

Perhaps if we actually wanted to ask this particular question in a quiz the
best thing to do might be to use a Text question or Matrix question to ask
the students for a pair of distinct integers each greater than lower bound
and then just grade the ordered pair. (Of course that wouldn't make a very
good illustration of the multiquestion syntax. :))

So this whole business of how the various answers depend on one another
seems to be a subtle one indeed. I think for now the best policy is to let
it as it is now, and leave it up to the question author decide what the
various dependencies should be on a case by case basis.

While we are on the topic of Neil's two-prime example question, the question
gives an error when a composite number is entered under Maple 9 w/ AIM dev
version.  I tracked down the problem and it turns out that the value ans1 is
not treated as a global variable in the two solution procs (causing an error
when it tries to evaluate @ifactor(ans1)@ in the `aim/t` line) even though
it is declared as a local variable at the top of the question.  A workaround
is to simply add the line

global ans1;

to the top of each solution proc.  I don't know if this is the intended
behavior, or if it is an artifact of Maple 9, but the workaround is probably
not such a bad idea anyway, so I won't post this as a bug.  For now I just
updated the example in format.html to include these global declarations and
committed the changes.

KEN