WeBWorK Problems

Permitting re-randomization of problems vs one fixed problem per seed

Permitting re-randomization of problems vs one fixed problem per seed

by tim Payer -
Number of replies: 1
Greetings, I am posting Danny Glin's response to re-randomization of a WeBWorK problem below at his suggestion that this issue might need its own thread. The re-randomization was a component of a problem from the thread "merging custom answer checkers with PostFilter AnswerHints". My response is also posted below.

Danny Glin writes:
I'll throw in my opinion here...

I think that WeBWorK problems should show consistent output when loaded with the same seed. Since there are mechanisms for re-randomizing problems within a homework set, I don't think it is necessary to perform the re-randomization within the problem. Also, for me the expected behavior is that when I load a WeBWorK problem it will always show the same version unless I've specifically requested that it be re-randomized.

This is the way that PG behaves, so it only gets complicated when using external integrations. The R server connection has been set up so that the problem seed from WeBWorK is passed to R, which means that the behaviour is consistent with PG. I would suggest that for other integrations (Sage, GeoGebra, etc.) that either the randomization be done in PG then passed to the external system, or that the problem seed be used to initialize the environment in the external system.

Not sure if this warrants its own thread?

In Reply to Danny Glin's point:

I do see your point about consistency of the problem for a given seed. I can see that there might be an issue between the instructor and student if the student sends an email prompt to the instructor on a given problem. Without the enforced consistency the instructor would be presented a different function than what the student had.

There might be other unforeseen problems with permitting this randomization that we have not considered.

What issues do you see if we proceed with this form of re-randomization?

Here was our thinking on why we wanted re-randomization of the "sketch the derivative" problem:

1.) Permitting a "reset" option in the problem gives the student an arena with which to practice these types of problem. Some students get the lesson with just a few attempts, but others need much more practice. Permitting re-randomization seems like a better approach in that it provides ample practice for those that need/want it and does not burden the student who has already learned the lesson by assigning more of these problems.

2.) The fixed problem set for a given seed has a vulnerability for students that want to "cheat" the problem. Once the sketch of the derivative is shown such a student can make a screen capture or take a picture with their cell phone and then use the derivative image to answer the problem on further attempts, effectively bypassing the lesson. Showing the derivative sketch is a needed option, yes, but we would rather the student not be able to submit a score for that particular function once the derivative was revealed. Here we would want the option to reset for new function.

(That said we wish we had half your programming skills!)

Best, Tim Payer

In reply to tim Payer

Re: Permitting re-randomization of problems vs one fixed problem per seed

by Danny Glin -
Assuming that you can pass the problem seed to GeoGebra, you can do what you desire using the built-in re-randomization in WeBWorK:


You would enable this feature, then set it to rerandomize the problem after 1 attempt.

The disadvantage of using the built-in WeBWorK re-randomization is that it doesn't give the student an opportunity to see the correct answer to the current version before moving on to a new version.

Of course you are always free to do whatever you want with locally created problems. I am more thinking about sharing problems with the OPL. When I assign a problem from the OPL, I make a few assumptions about how it operates. In particular, I expect that the problem will respect the settings available in the homework set, such as:
  • Number of attempts - the student should not be able to get any feedback until they submit their answers, which will count as an attempt.
  • Random seed - the problem shouldn't change unless the problem seed is changed, which can be done using the re-randomize feature.
These are my thoughts on problem authoring, and may not reflect the WeBWorK community at large.