unorderedAnswer.pl conflict with other answer checkers.

[jirilebl]

The following is a minimal example showing the problem. Basically if there are two answer blanks that are supposed to be unordered and then one that follows that has a normal answer checker. The problem never accepts the answers in any order and in fact. The "show correct answers" always shows the answers in the opposite order.

Removing the third answer checker fixes the problem, and so does moving to named unordered answer checkers.

I've looked at the code a little bit in unorderedAnswer.pl, but I can't quite see what's wrong.

Here's the minimal example. The answers should be "x,x^2,x+x^2" or "x^2,x,x+x^2"

DOCUMENT();      

loadMacros(
  "PGstandard.pl",
  "MathObjects.pl",
  "unorderedAnswer.pl",
  "PGcourse.pl"
);

TEXT(beginproblem());

Context("Numeric");

$sol1 = Formula("x");
$sol2 = Formula("x^2");
$soli = Formula("x+x^2");

Context()->texStrings;
BEGIN_TEXT
\( y_1 = \) 
\{ ans_rule(20); \}
$PAR
\( y_2 = \) 
\{ ans_rule(20); \}
$PAR
\( y = \) 
\{ ans_rule(20); \}
END_TEXT
Context()->normalStrings;

UNORDERED_ANS( $sol1->cmp(), $sol2->cmp() );
ANS( $soli->cmp() );

ENDDOCUMENT();    

[dpvc]

This is the documented behavior of the unordered answer macro. From the unorderedAnswer.pl file:

# ... If N answer checkers are given, then the last N answer
#  rules will be used.  It is beter to use named rules and UNORDERED_NAMED_ANS
#  below.  Otherwise, be sure to use UNORDERED_ANS right after the answer
#  rules for the answers you want to compare.

So if you are not using named answer checkers, you must put the UNORDERED_ANS() call immediately after the answer blanks it applies to. You can't have other intervening answer rules. So this is not a bug, it is a feature.

Of course, it is not a great feature, and perhaps the macro could be rewritten to do better. But it is a very old macro, and one before many of the current features were made available. The MultiAnswer object is often used in place of it these days.

[jirilebl]

I just noticed this too right after submitting this, that this is the "documented behavior". Really it is more like "documented bug" rather than "documented behavior". Still this is not clear from the wiki or the examples. So I've at least added a short cautionary note to the wiki since that's the first page that comes up as documentation for UNORDERED_ANS and it didn't mention this problem at all.

Still I'd consider this a bug, not a feature.

[jwj61]

As a bug, it is an issue for the pg repository rather than this one. I don't know of a way to have github transfer it, so I am closing it here.

[jirilebl]

Actually, where is the actual unorderedAnswer.pl file that gets used then? I can't find it in the pg repository, there are two versions of it and only in the OPL repo:

OpenProblemLibrary/macros/CollegeOfIdaho/unorderedAnswer.pl
OpenProblemLibrary/macros/Union/unorderedAnswer.pl

This was actually something that I've always wondered. A web search doesn't help on this question either.

By the way. Those two files differ slightly.

[jwj61]

OK, reopening

[dpvc]

The original file is

OpenProblemLibrary/macros/Union/unorderedAnswer.pl

and the one that gets used will depend on the value of $pg{directories}{macrosPath} in your course configuration. The default (in webwork/config/default.config) has the Union library before the CollegeOfIdaho version, so it is likely that you are getting the Union copy.

In the old days, before all the various individual college collections were unified in the OPL, different schools made their own macro collections, and some started with copies of the macros from other schools. (The macrosPath was not configurable in those days, so you couldn't just link in another directory like you can now.) So copies of macros proliferated, and are still seen today (similarly, individual problems were copied and edited, which lead to many similar but slightly different versions of the same problem).

[dpvc]

I don't know of a way to have github transfer it

@jwj61, there is a "Transfer issue" link just above the "Delete issue" link at the bottom of the right-hand sidebar. You can use that to move an issue from one repository to another, if you like.

[jwj61]

Thanks, I'll keep that in mind for the future.

[dpvc]

Still I'd consider this a bug, not a feature.

That's up to you. (But the usual terminology is that a bug is a result that is counter to the documented behavior, while a feature is a documented result. Since this is both documented and the intended result, it is not a bug. It may be a misfeature, but still a feature.)

When the macro was originally written, the macro did not have access to information needed in order to make it work the way you want. In order to do that, it would need to know the name of the next answer blank that needs to have an answer checker assigned to it; but that was not available within the safe compartment (where the UNORDERED_ANS macro runs), and so it could not work the way you wish it to. It does have access to the next answer blank name to be created, and could use that to determine the last n answer blank names that were previously created, which is how it works, and why it needed to be issued right after those blanks in order to operate properly.

Much has changed with the way answer blanks are generated in the 15 or so years since unorderedAnswer.pl was written, and it may be the case that you could get the needed information now. It might be possible to be clever about passing parameters to the n answer checkers that UNORDERED_ANS() produces in order to get everything to work as you would like. You are free to make a pull request that modifies the macro definition in order to overcome this shortcoming, if you wish.