Re: [WWdevel] problem groups (in gateway tests)

[P. G. L. <gl...@um...>]

> One concern is that even if we split source_file up into multiple fields 
> later, we still end up having to support this format for old set definition 
> files. Probably not a big deal.
>
> Another issue is not having a one-to-one correspondence between problems in 
> the "prototype" UserSet and problems in the versioned UserSet. If that seems 
> like a problem then the second solution would probably be better.
>

These were, essentially, my concerns, though not so well phrased.  I also 
wondered if there would ever be a case in which one might want to have two 
problems in a set drawn from the same group and not worry about excluding 
the possibility of a repeat.  In that each problem gets a different seed 
that might not be a bad thing in many cases, but I can't think of when it 
would be desirable.  In any event, having multiple problem entries in the 
UserSet and then just requiring that no group problems are repeated would 
prevent this.

Gavin

-- 
P. Gavin LaRose / Instructional Tech.,  The tough problem is not in iden-
Math Dept., University of Michigan      tifying winners;  it is in making
gl...@um...                       winners of ordinary people. That,
734.764.6454                            after  all,  is  the overwhelming
http://www.math.lsa.umich.edu/~glarose/ purpose of education.  -K.P.Cross

On Thu, 18 May 2006, Sam Hathaway wrote:

> On May 15, 2006, at 11:22 AM, P. Gavin LaRose wrote:
>
>> I think the logical way to do this is to refine the way problems are
>> selected from the group to include an indication of the number of problems
>> to be selected from the group.  That is, instead of having the set declare
>> a problem "group:topic1", have the declaration be "group:topic1:N", where
>> N is the number of problems to include.  Then when a new version of the
>> set is created and assignProblemToUserSetVersion is called, it would
>> actually add N problems to the user's set version.
>
> This looks good, and I think you should try it.
>
> One concern is that even if we split source_file up into multiple fields 
> later, we still end up having to support this format for old set definition 
> files. Probably not a big deal.
>
> Another issue is not having a one-to-one correspondence between problems in 
> the "prototype" UserSet and problems in the versioned UserSet. If that seems 
> like a problem then the second solution would probably be better.
>
> Speaking of which, I don't think option 2 would be that hard to implement. 
> assignSetVersionToUser could keep a hash and pass it by reference to 
> assignProblemToUserSetVersion, which would record the actual source files 
> chosen for each group and check the existing entries to rule out duplicates.
> -sam