** Using WeBWorK **

At Stockholm University we are currently trying to implement a "drill"-application within the WeBWorK-framework.

The purpose of the application is to supply the students with an "endless stream" of randomly selected problems from a topic selected by the student (e.g. Derivation:Intermediate). The student can work with the problems until they feel comfortable with it. (In the future the application will by itself move on to more advanced problems when a certain percentage of correct attempts have been made.)

Currently we have implemented this by a problem set with e.g. 10 problems which randomly selects their content from a list.

Our problem is to get a good solution to the seeding of SRAND. Currently we are using the session key as seed. This provides the student with a new set of problems at each login. This solution has two drawbacks:

1. The student can't log out and enter the solutions later at another session. 2. If the student uses the feedback-button the teacher will get another session key and thus another seed than the student. Furthermore when help arrives, the students session has already timed-out.

What (I think) I 'm looking for is a possibility to store the generated problem_seed in the database. Does anyone know how to accomplish this?

A more general question: Is there a best-practice for how the database APIs should be accessed from within a PG-file?

Many thanks,

Mats Oldin

<| Post or View Comments |>

This sounds quite a bit like the problem of giving versions of problem sets to users, which is something the GatewayQuiz module that I've been working on for a while has had to deal with. In this case, we're giving a student a problem set which s/he may work on through some specified number of submissions, after which s/he gets a new version of the set. For the gateways we use the number of submissions is one, but the idea should be more flexible than that.

The way the GatewayQuiz module deals with this is by defining an 'assignment_type' field in the set table (and user set table) of the database, and using this to determine if the set is a versioned or normal set. If it's versioned, the module checks if a new version should be created, and then builds one. The result is that a user is assigned the 'template set', say, "GatewayQuiz 1", and then as s/he takes the test multiple times gets new versions assigned to her/him: "GatewayQuiz 1,v1", "GatewayQuiz 1,v2", etc. The original template set ("GatewayQuiz 1") isn't ever completed by the student.

The result of this process is that we store successive sets, each of which will have a different set of problems or problems with different seeds.

Obviously, the biggest difference is that this is talking about giving different versions of a set, while you were talking about giving different versions of a problem, but I think the ideas aren't too far distant from each other.

Cheers,
Gavin

(I should add that the GatewayQuiz module is generally functional, residing in the HEAD version of WeBWorK in the CVS, and we're going to be testing it heavily this semester.)

<| Post or View Comments |>

Thanks for your advice. I've been looking in to the GatewayQuiz module and I'll think we will get something working by "stealing" suitable pars of it :)

When I tried to use it however, I ran into some problems. When I changed the type of a homwork set to "gateway/quiz" I got some error messages.

First the compliator couldn't find the definition of "debug". After I had commented out these calls I could create a "gateway/quiz".

But when I followed the link "Take new TestGW test" I got the following:

Warning messages: * Argument "" isn't numeric in subtraction (-) at /opt/webwork2/lib/WeBWorK/ContentGenerator/GatewayQuiz.pm line 611.

Since I'm not so acquainted with the code I'm not sure what this can be caused by. I would be greatful for any advice on this.

Could it be that I've got a test snapshot from the CVS. If so is there any "stable" tag I could try?

Cheers,

Mats

<| Post or View Comments |>

The version in the CVS is the latest version; there isn't a version tagged "stable" yet. We're planning on running a big beta test here at Michigan starting next week, however, which I hope will result in my getting the majority of the remaining bugs worked out.

More specifically, the 'debug' error was, I thought, fixed by Sam sometime in the recent past. I haven't been running the system in debug mode, and so hadn't included that in the module. The non-numeric subtraction error I can't immediately say anything about. I'll go back and look at it again shortly, however, hopefully getting it fixed.

Thanks,
Gavin

<| Post or View Comments |>