|using existing answer evaluators as filters||topic started 8/27/2003; 3:32:38 PM
last post 8/28/2003; 9:20:00 AM
|Michael Gage - Re: using existing answer evaluators as filters
8/28/2003; 9:20:00 AM (reads: 1399, responses: 0)
Yeah, I've lost a lot of time over the years on the double tilde problem as well (and I wrote the interface!). Unfortunately it seems still seems the best compromise between the requirements of using backslashes in tex and backslashes in perl.
The possibility of reusing code to modify existing answer evaluators is one I'm very interested in and your
needs provide a good example of what facilities need to be made available. The implementation of the
"filter" framework for answer evaluators is a good step in this direction -- but I'm afraid it stalled a bit once I
had satisfied my immediate needs.
What's most needed is documentation and tutorial examples. At the moment
there is only a little documentation in AnswerHash and the rest of the purpose and functionality has to be inferred from some of the better code examples, such as fun_cmp and reading the code in AnswerHash and AnswerEvaluator.
The other two needs I've been aware of are to (1) modify the answer evaluator method so that filters can be either anonymous subroutines (for simple procedures) or answer evaluators (when more complicated processes are involved) and (2) to rewrite all of the current answer evaluators to correspond to the new scheme.
I know that John Jones has been pretty active in writing new answer evaluators using the "filter" framework. Perhaps he, you and others have further suggestions for the answer evaluator framework.
I'm in the midst of setting up fall courses, so it will be a week or so before I can look more closely and what you have working above. I would like to call attention to two subroutines in PGanswermacros.pl for handling options in a uniform way:
both in PGanswermacros.pl.
It's my current thinking that it is a good idea to include these in any but the most trivial of filters or
answer evaluators. They may not be important right away, but as people modify the filter, adding options
etc. , the presence of those subroutines will encourage the programmers to use them. In the future these subroutines themselves might be modified to allow discovery of available options, better debugging features,
and other improvements, so it would be helpful if they were in widespread use so that new features are immediately available to old answer evaluators.
Glad you're playing with this feature.