FITB (randomizable) outside of #exercise

[D. Brian Walton]

When the randomizable FITB sub-project was begun, a decision was made to restrict the option to #exercise, primarily to ensure that there was a localized focus on behavior. I hope to post an update and documentation this week so that it can be more publicly known.

In the process of writing the documentation, I've been thinking about the restriction to #exercise. I think it should be relatively straight-forward to open to other exercise-like environments (project/activity/exploration/investigation), but #task seems a little trickier because presumably tasks are linked with other related tasks.

I think there is a technical hurdle for Runestone Components to deal with randomization across multiple related components (tasks). I see two  basic strategies right now: (1) Each task is provided the same seed for the random number generator and so each task regenerates the necessary variables or (2) The parent block controls the seed, underlying environment variables are affiliated with the parent block, and components reference variables through the parent.

I think option (1) is easier to implement. Individual component behavior would be essentially the same as currently exists. The complication is that the seed control and rerandomization needs to be at the parent's level, which does not actually have an associated Runestone Component. Maybe the first/ component in the chain is what controls the seed/rerandomization?

Option (2) feels more holistically correct. There would be only one underlying environment of variables. Individual components would not be standing on their own, and that feels like a departure from current philosophy. I think there is similar difficulty in figuring out how related components are informed of a re-randomization for both methods.

If there was the ability for an exercise with multiple tasks to be dynamically generated, where would it make the most sense to put the control to be able to re-randomize? It doesn't feel to me like this belongs to a single component (i.e., single task), which means the control is somehow outside of the associated Runestone Components.

- Brian

[Andrew Scholer]

I think #1 has some potential tricky bits around components that have overlapping but not identical lists of variables. If they are all given the same seed, but then do different series of operations with that seed (one generate A,B,C and the next generates C and D as it builds on the answer from the first), they will compute different values for C. That sounds like a lot for an author to be aware of (or for the system to avoid on behalf of an author).

So I like #2.  But it does mean defining variables on pretext elements that do not directly use the variables. Figuring out where you are allowed to do that feels like a small pain point for authors. And what happens if a question is viewed out of context? Say an instructor in Runestone assigns a problem that uses random variables but not other related problems. That either needs to be somehow prevented or handled.

Maybe instead of defining an explicit scope for variables by attaching them to a particular pretext element, an author has to identify a shared variable where it is defined - give it some kind of unique id (probably different than the value used to author the rest of the question). Then they can reference that variable using the id in other spots via that id ("make C be a copy of that variable defined as Ch1_sequence1_C"). PreTeXt could create an index of the variables with the necessary initialization information and dump it into the Runestone manifest. Runestone could read that and store it in the DB. When a RS component needs a particular shared variable, it could ask a singleton VariableManager to retrieve the existing value or create a new random one if it has not yet been used on the page. That idea would be extra engineering. But something like that would give maximal usage flexibility. And I think it might be necessary for using the questions after they are broken up and repackaged into an assignment.

In terms of where to allow re-randomization, I think that control needs to be in each question for the same issue around repackaging individual questions into an assignment page.

Andrew Scholer (he/him/his)

Computer Science Instructor/Program Chair

Chemeketa Community College

503.589.7649 

computerscience.chemeketa.edu/people/andrew-scholer/

--
You received this message because you are subscribed to the Google Groups "PreTeXt development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pretext-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pretext-dev/CAH7VRoJq4pmtGPtYPogTkUoePwnEpiiKpErvJkJvdpShQRgjKg%40mail.gmail.com.

[D. Brian Walton]

Andrew,

Thanks for thinking about this and responding. I'll have to think about the idea of a VariableManager. At the moment, I'm not sure if things really get separated too far from each other. The inclusion of #task means that all tasks belong to some common exercise-like object. I haven't thought about communication between different elements on a page.

If an exercise-like element that involves tasks is imported to Runestone, are the individual #task elements independent components? I guess they probably are and would lose their connection to the other tasks except in the context of an individual page. I think this is the hurdle that I'll need to resolve.

Brian

To view this discussion on the web visit https://groups.google.com/d/msgid/pretext-dev/CACm44N-tKPFkdiA3nZFefqGZtO3yKPhgwUzZvc0VsCJ%3D22n6eA%40mail.gmail.com.