WeBWorK problems re-randomizing

[Chrissy Safranski]

The usual behavior of WeBWorK problems in PreTeXt is that there's a static version, but hitting Activate gives a randomized dynamic version, and that's the one students should enter answers for. 

We've run into 3 problems (so far!) where the version that appears after Activate is not the "real" version - the problem re-randomizes itself after hitting "Submit" or "Check Responses" or whatever.  It appears that this 2nd dynamic version is the one that stays (and is possibly always x^2??).  

You can see this behavior here: Exercise 2.: Solid of revolution from one function about the 𝑦 -axis

The source of the 3 problems we've seen this for are Library/Michigan/Chap8Sec2/Q22 and Library/Michigan/Chap8Sec2/Q23 and Library/Michigan/Chap8Sec2/Q24 and Alex tracked down that these problems have this line in them which is responsible for the re-randomizing: 

# make this have the same root as the following
SRAND($psvn);

I think this is more of a notification than a request for support.  That line in WeBWorK problems currently doesn't play very nicely with their inclusion in PreTeXt, and is especially irritating to students in Runestone where their responses are collected and graded (they did the first dynamic version as usual, got marked wrong when they hit submit, and the problem changed on them).  But it's not a common thing to run into, and it probably does work as intended in standalone WeBWorK.

Chrissy

[Alex Jordan]

That use of SRAND is intended to make those exercises use the same
random numbers as a student progresses from one exercise to the next
in a regular WeBWorK exercise set. I suspect that when the problem
first loads, $psvn is undefined. But after the first submission, it is
defined, possibly empty.

I have an idea that might normalize $psvn. As with the restoring of
old answers, I can't prioritize it right now. I have too much local
work with deadlines. But in the meantime, can you say exactly where
these exercises are used in the Active Calculus Runestone course? When
I try my idea, I will want to look there to see what effect it has on
these exercises.

Also I need to check with you. If I do something about this, it might
necessarily mean that random versions that a student has right now
will have to become some different random version if my idea works.
Will that be OK?

> --
> You received this message because you are subscribed to the Google Groups "PreTeXt support" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to pretext-suppo...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/pretext-support/1dbbc8b9-00e3-4fcb-b080-74bb6ca5e0cbn%40googlegroups.com.

[Chrissy Safranski]

They're in Section 6.2, Using Definite Integrals to Find Volume.  They're numbers 2, 3 and 4 in my version, and it looks like Matt's version has another one of them, so it's numbers 2-5 in the same section.

My students' homework on that section is due tomorrow (Wednesday) at 5pm Eastern.  It might not be good to do too much changing of the problem before then in case it would add to their frustration while they're working, but after that time is fine.  

Chrissy

[Alex Jordan]

The idea I wanted to try does not work. I thought I could pass a value
for psvn based on the id of the Runestone course to get consistency of
the result from SRAND($psvn). But on the WW end of things, it is not
using the value of psvn that I pass in the form. It is looking up
$psvn from scratch internally.

So I don't know what to do. I don't think that problems should be
coded in this way in the first place. It's a PG problem that depends
on something that is part of webwork2 infrastructure. Therefore the
"right" thing to do is to change these problems in the OPL. The author
wanted three different PG files that all had the same randomization.
But it could just be one PG problem with three parts.

I could apply band-aids, like changing these problems on the AIM
server, commenting out the SRAND($psvn) command. Or hard coding
SRAND(1) or something like that. I would prefer not to do that kind of
thing so that the AIM OPL doesn't get out of sync with the real OPL.

> To view this discussion on the web visit https://groups.google.com/d/msgid/pretext-support/5d9860b1-9d2b-40b1-b3fd-5b2c252b18d6n%40googlegroups.com.