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: Thursday, September 04, 2003 4:54 AM
> To: AIM developers
> Subject: RE: [Aimmath-developers] Multipart questions ... a little trap
>
> The original proposal was to allow an arbitrary number of answerboxes
embedded
> anywhere within the text of the question. One possible syntax would
> be to include the answerboxes inside the t> flag as something like
> %(type,size)
> where type is the required Maple type of the anwer and size is the size of
> the box.
>
> t> Find two primes $p_1$ and $p_2$ such that $p_2 > p_1 > @lowerbound@$.\\
>    $p_1=$ %(posint,4) and $p_2=$ %(posint,4).
> s> [ proc(ans1,ans2) ......

Yes, I would like to see this type of question some day.  I suggested
something similar to this to the JISC list last November.  WeBWorK already
has exactly this capability, for example.  I would modify your suggestion
slightly so the answerbox syntax would be:

%(name,type,hsize,vsize)

so that we can specify the horizontal and vertical size to each answer box
(for example, if you want to make a survey or essay question with a very
large answer box (if hsize or vsize are omitted they would have a default
value). By naming the answer boxes we could just return a single table as
the student's answer, i.e.

> t> Find two primes $p_1$ and $p_2$ such that $p_2 > p_1 > @lowerbound@$.\\
>    $p_1=$ %(p,posint,4) and $p_2=$ %(p2,posint,4).
> s> [ proc(ans)
         if isprime(ans[p1]) and
            isprime(ans[p2]) and
            ans[p1]<ans[p2] and
            lowerbound < ans[p1] then
          return 1;
         else
          ......

We could call this a TableQuestion, since it returns a table instead of a
Matrix.  The advantage to naming this is that it makes the coding a bit more
readable when you have many answer boxes, and if you later reformat the
question to put the answer boxes in a different order or if you randomize
the wording of the question so that the boxes randomly occur in a different
order, you could have a single solution proc that doesn't need to take the
order of the boxes into account.

In this case the validation mechanism would not accept any student answers
unless all of the boxes satisfied the correct type, and all boxes would be
graded simultaneously each time.

Another possible syntax might be

%(type,name,hsize,vsize)

so that if 'name' is omitted, the question boxes are just numbered in order
1,2,3, so that in the s> proc we would have ans[1], ans[2], etc.  That way
naming the boxes would be optional.  I like your idea of putting the type in
the answer box specifier.  I guess if that was omitted too it could default
to 'anything', so that %() would be the minimalists answer box. :) Actually,
to be consistent with the @-substitution syntax, perhaps the answerbox
syntax should be

%type,name,hsize,vsize%

Anyway this is definitely on the wish list for future AiM.  I don't think we
will have it before Monday though. :)

KEN