WeBWorK Problems

ans_array

ans_array

by Alex Jordan -
Number of replies: 5
I am trying to understand the "ans_array" subroutine as part of efforts to get PreTeXt to work with problems that use "ans_array". After some exploring, it seems to me there are two versions of this macro. One is in the Value package (with variants for Point, Vector, Matrix, and Formula Math Objects). If $M is a math object and you use $M->ans_array(), you get an array of answer blanks. I understand this and I believe I understand the code that builds these answer arrays.

Then in PGbasicmacros.pl (as well as in PGmorematrixmacros.pl) there is also an "ans_array" subroutine. Both of these essentially rely on the "display_matrix" subroutine in PGmatrixmacros.pl. You would use this one like: \{ans_array(2,1,5)\}. It doesn't appear designed to be used like $M->ans_array() for any kind of $M.

I'm finding it difficult to understand the code for "display_matrix". But it made me wonder, is this second "ans_array" really even used anywhere? I grepped the OPL for '[^>]ans_array' and I only had six hits. Four of them are just mentioning "ans_array" in a comment, and the code uses the Value version of "ans_array". One of them turned out to be defining its own subroutine called "build_ans_array". Only one problem file in the entire OPL appears to be using the PGmorematrixmacros.pl ans_array. (WHFreeman/Holt_linear_algebra/Chaps_1-4/4.2.5.pg). It seems nothing in the OPL at all is using the PGbasicmacros ans_array.

I also tracked each use of "ans_array" in pg/macros and the OPL macros and found nothing except comments and use of the Value "ans_array".

My question is: Is the PGbasicmacros.pl "ans_array" subroutine used for anything at all? Can I safely ignore it as I try to improve the PreTeXt-WeBWorK connections? (Pushing further, can we clean up PGbasicmacros.pl by deleting things that can be demonstrated to not be in use?)
In reply to Alex Jordan

Re: ans_array

by Danny Glin -
The PGmorematrixmacros.pl ans_array predates Math Objects, and was a convenient way to create a matrix of independent answer blanks (i.e. each one was associated with an independent answer checker). It looks like almost all of the OPL problems have been updated to use the Math Objects tools, so the standalone ans_array is mostly deprecated.

The only concern would be backwards compatibility with local problems that people have written. I know I have some here that still use ans_array, but I'm not opposed to having to update them to work with new WeBWorK features.
In reply to Danny Glin

Re: ans_array

by Alex Jordan -
Thanks Danny,

I'm feeling good now about ignoring these things for PreTeXt work.

Maybe we should make PGdeprecations.pl, and move things like the PGbasicmacros' ans_array into there to start cleaning up. PGbasicmacros.pl could still call upon PGdeprecations.pl so that no problems break. But we could insert into each macro some warning message or something that only appears when some debugging flag is on. Or something like that. In general I feel that cleaning up the code would be good for getting new contributors.

Alex
In reply to Alex Jordan

Re: ans_array

by Sean Fitzpatrick -
I can say from experience that cleanup would make it easier for people to get started on problem authoring.
We spent a whole summer with a hired student working full time just to go through all the different possibilities for authoring different types of questions, figure out what's best practice, etc.

Chances are that of the few still using old problems relying on these macros, none are interested in importing them into a PreTeXt document.
And if I'm wrong on this, probably PreTeXt processing (in the mbx script probably) there can be - or already is - an error message saying "Sorry, but this problem isn't PreTeXt-compatible."
In reply to Alex Jordan

Re: ans_array

by Michael Gage -
I'd support that. There are already a few commands that come with deprecated warnings but putting them in a separate file is a good idea.


In reply to Michael Gage

Re: ans_array

by Danny Glin -
I would go a step further and set the default behaviour in the next version of ww to disallow these deprecated commands. As already mentioned there could be a flag to enable them, but having them default to disabled might force people to update their problems.

Related to coding best practices, we should set up a few sample questions as good places to start when authoring. Perhaps this would just involve updating the Problem Techniques section of the wiki.