openwebwork-devel

[WWdevel] Backward-compatible Parser-based answer checkers

[Davide P.C. <dp...@un...>]

Folks:

Over the long weekend, I have been working on a method of making the 
traditional answer checkers (like std_num_cmp() and fun_cmp()) use the 
new Parser, and I have a working version of PGanswermacros.pl that 
implements it.  It turns out not to have been as difficult as I thought 
it might be, and I think I was able to map all the various parameters 
onto corresponding Parser parameters successfully.  Of course, this is 
a pretty major switch, so there will be some problems, I'm sure.

I have created a new subdirectory of the Parser tree that contains the 
needed files.  It is pg/lib/Parser/Legacy, and there is a README file 
there that explains how to install and use it.  You should also update 
your copy of the Parser and Value packages, as there are some changes 
within them that I made while working on this.

Since PGanswermacros.pl is preloaded (unlike most .pl files), this 
means that the change has to be made for the whole server at once.  I 
have arranged, however, for the original answer checkers to remain 
available, and you can switch back on a site-wide, course-wide or 
problem-by-problem basis.  If you turn the new checkers OFF for the 
site, and ON for problem files that you want to test, you should be 
able to try this out even on an active system without causing trouble 
for existing courses.  Again, see the README for details.

All the changes to PGanswermacros.pl are in NUM_CMP and FUNCTION_CMP, 
which have been essentially replaced by functions that set up an 
appropriate Parser context, create a Parser object from the correct 
answer, and return its answer checker.  This effectively turns all the 
traditional answer checkers into ones that use the new Parser in a 
backward compatible way so that existing problem files do not need to 
be modified.  Any answer checkers that rely on the standard ones (like 
the ones in the union_problib) will also be taking advantage of the new 
Parser.  Note, however, that these replacement NUM_CMP() and 
FUNCTION_CMP() do not necessarily store the same values and fields in 
the AnswerHash, so code that takes advantage of private data from a 
checker's AnswerHash may no longer operate correctly.

I have not done a huge amount of testing in existing problem files, but 
I did run through some of the more complicated ones from the Union 
problem library that used nested answer checkers, and they seem to work 
OK.  Let me know if you try this out, and what results you get.  I'm 
sure it is not a finished product.

Davide

Re: [WWdevel] Backward-compatible Parser-based answer checkers

[Michael E. G. <ga...@ma...>]

Hi Davide,

This looks really neat.

I volunteer to look into rewriting BASIS_CMP to using the MultiPart 
object
unless someone thinks this is a bad idea.

Take care,

Mike

Re: [WWdevel] Backward-compatible Parser-based answer checkers

[Davide P.C. <dp...@un...>]

> This looks really neat.

Thanks, I think it is a step in the right direction.

> I volunteer to look into rewriting BASIS_CMP to using the MultiPart 
> object
> unless someone thinks this is a bad idea.

It is worth trying out.  One thing to keep in mind:  the MultiPart 
object is intimately tied to the Parser objects, so it only works with 
Parser-based objects (and not with other answer checkers, including the 
retro-fitted tranditional ones).  Also, remember that the answer blanks 
are produced by the MultiPart object, so you need to create it BEFORE 
the answer blanks are generated.  That means it probably will require 
changes in the problem file.

Davide

Re: [WWdevel] Backward-compatible Parser-based answer checkers

[Michael E. G. <ga...@ma...>]

Hi Davide,

OK.  I have one conflict.

The terms such as    $matrix = new Matrix;

(Matrix is the old style matrix) are not working -- probably a
conflict with the Parser::Matrix objects.

Nearly any example that uses PGmorematricmacros.pl or
PGdiffeqmacros.pl will give an error about not being able
to recognize Matrix.

Error detected while loading [PG]/macros/PGmorematrixmacros.pl: 
Bareword found where operator expected at line 11 of 
[PG]/macros/PGmorematrixmacros.pl, near "new Matrix"  Died within 
main::compile_file called at line 263 of [PG]/macros/dangerousMacros.pl 
  from within main::loadMacros called at line 8 of 
[TMPL]/setLinearAlgebra3Matrices/ur_la_3_23.pg


I'm starting to look at it, but you may have a better idea
of where to look.

It's not 100% guaranteed that this is due to your changes.
I've been making some as well.


Take care,

Mike

Re: [WWdevel] Backward-compatible Parser-based answer checkers

[Davide P.C. <dp...@un...>]

> OK.  I have one conflict.
>
> The terms such as    $matrix = new Matrix;
>
> (Matrix is the old style matrix) are not working -- probably a
> conflict with the Parser::Matrix objects.
>
> Nearly any example that uses PGmorematricmacros.pl or
> PGdiffeqmacros.pl will give an error about not being able
> to recognize Matrix.

OK, I'll look into it.  The only thing I can think of that would cause 
this is the presence of the Matrix subroutine (which is being defined 
by Parser.pl, which PGanwermacros.pl now loads).  Parser::Matrix won't 
conflict directly with Matrix, or we would have seen that long ago, I 
think, as the Parser::Matrix package has been loaded with the Parser 
from the very beginning.

Davide

Re: [WWdevel] Backward-compatible Parser-based answer checkers

[John J. <jj...@as...>]

First, a big thanks Davide for doing this.

Has this issue with Matrix been resolved?

John


Michael E. Gage wrote:

> Hi Davide,
>
> OK. I have one conflict.
>
> The terms such as $matrix = new Matrix;
>
> (Matrix is the old style matrix) are not working -- probably a
> conflict with the Parser::Matrix objects.
>
> Nearly any example that uses PGmorematricmacros.pl or
> PGdiffeqmacros.pl will give an error about not being able
> to recognize Matrix.
>
> Error detected while loading [PG]/macros/PGmorematrixmacros.pl: 
> Bareword found where operator expected at line 11 of 
> [PG]/macros/PGmorematrixmacros.pl, near "new Matrix" Died within 
> main::compile_file called at line 263 of 
> [PG]/macros/dangerousMacros.pl from within main::loadMacros called at 
> line 8 of [TMPL]/setLinearAlgebra3Matrices/ur_la_3_23.pg
>
>
> I'm starting to look at it, but you may have a better idea
> of where to look.
>
> It's not 100% guaranteed that this is due to your changes.
> I've been making some as well.
>
>
> Take care,
>
> Mike
>

Re: [WWdevel] Backward-compatible Parser-based answer checkers

[Davide P.C. <dp...@un...>]

>  First, a big thanks Davide for doing this.

You're welcome.  I thought it would be an interesting experiment.

>  Has this issue with Matrix been resolved?

Yes and no.  There is not longer an immediate conflict when a problem 
uses the traditional Matrix class.  But if a problem author would want 
to use both the new parser and the old matrix class in the same 
problem, then loading "Parser.pl" would cause a conflict.  But the 
conflict is only with the subroutine called "Matrix()" not with the 
classes themselves.  In that case, you could call Matrix->new() to get 
the matrix rather than "new Matrix()".  So it is not such a serious 
problem as it might have seemed at first.

Davide

Re: [WWdevel] Backward-compatible Parser-based answer checkers

[Michael E. G. <ga...@ma...>]

Hi Davide,

The conflict of the two versions of Matrix is real.  When I rename my 
version to
MatrixReal (and the file goes from Matrix.pm to MatrixReal.pm) then the 
problem goes
away.  For this test I just changed the one occurrence of Matrix in 
PGdiffeqmacros.pl.

I was always a little puzzled as to why this conflict didn't come up 
before.  I assume
because your type is really Parser::Matrix.

Take care,

Mike

[WWdevel] A table of existing macros

[Michael E. G. <ga...@ma...>]

Hello all,


I've made a chart of most of the macros currently available for use in
WeBWorK problem  (this includes macros from union_problib/macros, but  
not
yet the macros from nau_problib/macros)

It was made essentially by searching   for
/^sub /
in the macro files, followed by a bit of text cleaning.  You can find  
them displayed
on the twiki at

http://devel.webwork.rochester.edu/twiki/bin/view/Webwork/PGmacrosByFile

and at

http://devel.webwork.rochester.edu/twiki/bin/view/Webwork/ 
PGmacrosSortedAlphabetically

The first link is easier to keep up to date.  The chart is already  
slightly obsolete since I've made some changes in the macro files.  I  
am also writing notes indicating which subroutines should be  
deprecated, which ones are really obsolete and should never be used,  
which ones are actually internal and should not be available to a  
problem writer and so forth.

It's on the twiki, so you are all invited to help with the editing and  
notating.

There are over 900 macros -- way too many -- so some consolidation is  
in order and the place to start would be to try to get a handle on what  
has already been produced and how they overlap.

One of my desires is to replace the calls such as

strict_num_cmp( $ans, .001,'%0.5f')
by
num_cmp($ans, relTol=>.001, format=>'%0.5f', mode=>'strict')

and

strict_num_cmp_list(.001, '%0.5f',$ans1, $ans2, $ans3);

by

num_cmp([$ans1, $ans2, $ans3], relTol=>.001, mode=>'strict',  
format=>'%o.5f');

perhaps a dozen different subroutines can be replaced by using num_cmp
with either a single answer, or a reference to an array of answers and  
then
followed by a list of parameters.

This is fairly similar to the style that Mathematica uses and I think  
that it will be easier
to remember, document and maintain.

I'm thinking of placing these calls in a "PGcompatibility.pl" file  
where they can
be called for those who want to use them, but taking them out of  
PGanswermacros.pl
and modifying the problems in rochester_problib that use them.

Similar savings can be made with the fun_cmp family.

This will also cut down substantially on the size of PGanswermacros.pl

I invite your comments.  Reply to this list.

Take care,

Mike

Re: [WWdevel] A table of existing macros

[Davide P.C. <dp...@un...>]

> I've made a chart of most of the macros currently available for use in
> WeBWorK problem  (this includes macros from union_problib/macros, but 
> not
> yet the macros from nau_problib/macros)

This looks like a good start, and a useful thing, though it is going to 
be a pain to maintain.  I wonder if we should institute some kind of 
coding convention to help automatically separate the internal routines 
from the public ones.  (Or do you envision maintaining this by hand 
from now on?)

I'm not quite sure I think the last column is necessary, as it is 
usually incomplete.

> There are over 900 macros -- way too many -- so some consolidation is 
> in order and the place to start would be to try to get a handle on 
> what has already been produced and how they overlap.

In addition to the suggestions that you recommend concerning the older 
anser macros, quite a few of the parser-based routines are internal and 
shouldn't be listed.  For example, pretty much everything in 
context*.pl is internal.  You might even consider not including any of 
the parser stuff here, as that is a whole other ball of wax, and only a 
portion of its routines are in .pl files.

This brings up the point that there are many important macros that are 
part of the .pm files in pg/lib rather than .pl files in pg/macros.  
The various list macros come to mind, and so on.  Should they be 
included here?

Also, some of the routines listed are part of packages and can't be 
called directly.  They either are object methods, or require package 
names (package::routine).

> One of my desires is to replace the calls such as
>
> strict_num_cmp( $ans, .001,'%0.5f')
> by
> num_cmp($ans, relTol=>.001, format=>'%0.5f', mode=>'strict')
>
> and
>
> strict_num_cmp_list(.001, '%0.5f',$ans1, $ans2, $ans3);
>
> by
>
> num_cmp([$ans1, $ans2, $ans3], relTol=>.001, mode=>'strict', 
> format=>'%o.5f');
>
> perhaps a dozen different subroutines can be replaced by using num_cmp
> with either a single answer, or a reference to an array of answers and 
> then
> followed by a list of parameters.

This is admirable, but I'm not holding my breath to see people convert 
their old problems or stop using the older forms in new ones.  If you 
do actually remove them from PGanswermacros.pl, that will break lots of 
existing problems, and while that will force them to update (or at 
least to add PGcompatibility.pl to those files), it will also be a big 
aggravation to them.  The huge number of different forms of these 
macros is a pain, though, so I understand the desire to eliminate some 
of them.

It would not be too hard to write a script that does that conversion, I 
would expect.  That would help people out.

Davide

Re: [WWdevel] A table of existing macros

[Michael E. G. <ga...@ma...>]

On Jul 5, 2005, at 8:02 AM, Davide P.Cervone wrote:

>> I've made a chart of most of the macros currently available for use in
>> WeBWorK problem  (this includes macros from union_problib/macros, but  
>> not
>> yet the macros from nau_problib/macros)
>
> This looks like a good start, and a useful thing, though it is going  
> to be a pain to maintain.  I wonder if we should institute some kind  
> of coding convention to help automatically separate the internal  
> routines from the public ones.  (Or do you envision maintaining this  
> by hand from now on?)
>
I can recreate it by hand if need be.  It's a pain and takes an hour or  
so to clean it up using BBedit. Eventually I could automate it if it  
proves useful.  It will be even more of pain to maintain the comments.   
For the moment I view it as a transitional document, to see where we  
are and what needs to be done.

> I'm not quite sure I think the last column is necessary, as it is  
> usually incomplete.
>
The third column is really for comments.  For those items that haven't  
been commented on it
just contains "{ " and sometimes a little code or a comment.  I was too  
lazy to clean the code, even though it's not hard to do.  Sometimes the  
comment is useful.

>> There are over 900 macros -- way too many -- so some consolidation is  
>> in order and the place to start would be to try to get a handle on  
>> what has already been produced and how they overlap.
>
> In addition to the suggestions that you recommend concerning the older  
> anser macros, quite a few of the parser-based routines are internal  
> and shouldn't be listed.  For example, pretty much everything in  
> context*.pl is internal.  You might even consider not including any of  
> the parser stuff here, as that is a whole other ball of wax, and only  
> a portion of its routines are in .pl files.
>
> This brings up the point that there are many important macros that are  
> part of the .pm files in pg/lib rather than .pl files in pg/macros.   
> The various list macros come to mind, and so on.  Should they be  
> included here?
>
The list is still incomplete.  It does not include the .pm files or any  
of the NAU files.  Most of the .pm methods  are either internal
or high-level, but not all of them.   I included the parser files  
mainly because I wanted to reveal any overlap with existing routines.   
That helps us understand which macros can be retired.

I view this document as useful to developers more than to problem  
writers and other users.  An abortive attempt to write manpages for the  
useful and common routines is listed at  
http://webhost.math.rochester.edu/webworkdocs/docs/pglanguage/manpages/ 
.  It  is bogged down because I'm the main contributor and because the  
best input method is using the radio/frontier outliner.  I suspect that  
I could generalize the input to handle any outliner that
uses OPML as an output or export format.  (I also have an poorly  
maintained script that will produce TeX output from the same outlines.)  
  I like the format for the routines (which I borrowed from  
docserver.userland.com), but I'm not wedded to the input mechanism.  If  
someone has a good idea of how to easily input and maintain the data  
currently in the manpages -- particularly if we can reformat that same  
data for TeX or XML or other formats, let's hear it.  Good manpages are  
becoming a high priority.

> Also, some of the routines listed are part of packages and can't be  
> called directly.  They either are object methods, or require package  
> names (package::routine).
>
>> One of my desires is to replace the calls such as
>>
>> strict_num_cmp( $ans, .001,'%0.5f')
>> by
>> num_cmp($ans, relTol=>.001, format=>'%0.5f', mode=>'strict')
>>
>> and
>>
>> strict_num_cmp_list(.001, '%0.5f',$ans1, $ans2, $ans3);
>>
>> by
>>
>> num_cmp([$ans1, $ans2, $ans3], relTol=>.001, mode=>'strict',  
>> format=>'%o.5f');
>>
>> perhaps a dozen different subroutines can be replaced by using num_cmp
>> with either a single answer, or a reference to an array of answers  
>> and then
>> followed by a list of parameters.
>

> This is admirable, but I'm not holding my breath to see people convert  
> their old problems or stop using the older forms in new ones.  If you  
> do actually remove them from PGanswermacros.pl, that will break lots  
> of existing problems, and while that will force them to update (or at  
> least to add PGcompatibility.pl to those files), it will also be a big  
> aggravation to them.  The huge number of different forms of these  
> macros is a pain, though, so I understand the desire to eliminate some  
> of them.
>
> It would not be too hard to write a script that does that conversion,  
> I would expect.  That would help people out.
>
Many of the people who might be most aggravated are using un-retouched  
versions of the rochester problem library.  By updating the library  
either by CVS or by tarball they'd have working problems.   
Unfortunately the aggravation will increase rather than decrease with  
time.  Since there are a number of new problem developers coming on  
board now, and hopefully new cleaned up problems will arrive by the end  
of the summer, now is probably as good a time as any to clean house.   
Writing transition scripts is also a good idea.

Take care,

Mike

> Davide
>

Re: [WWdevel] A table of existing macros

[John J. <jj...@as...>]

Are these a collection of conversion scripts, or one which you are 
successively improving?  In any case, I should get a copy when they are 
done so I can run them on the "database-library" problems.

John


Michael E. Gage wrote:

>
> On Jul 6, 2005, at 11:58 AM, Davide P.Cervone wrote:
>
>>> This script is great.
>>> I've converted the rochester problem library and haven't found
>>> any glitches yet.
>>
>>
>> I'm glad it is working out for you.
>>
>>> I think we should add the string compare functions as well.
>>
>>
>> OK, no problem.  I'll add them to the table of routines to convert.  
>> I notice in PGanswermacros.pl that in addition to setting the 
>> filters, they also set a type flag.  Do you want that to be included 
>> in the conversion?  That is, should
>>
>>     strict_str_cmp("foobar")
>>
>> produce
>>
>>     str_cmp("foobar",filters=>'trim_whitespace')
>> or
>>     str_cmp("foobar",filters=>'trim_whitespace', type=>'strict_str_cmp')
>>
>> I think it should be the former, but I don't know how the type flag 
>> might be used later on, if at all.  I suspect it is just 
>> informational and can be ignored.
>>
> I think the former is best as well.  The type sets a flag in the 
> AnswerHash to 'strict_str_cmp' (the default is 'str_cmp') in case some 
> filter needs to know what kind of answer_evaluator  it is dealing 
> with.  So far it's most useful when trying to debug an answer 
> evaluator.  I think
> we can use 'str_cmp' as the answer evaluator type for all of the 
> special cases.
>
>> Also, do you prefer
>>
>>     str_cmp("foobar",filters=>'trim_whitespace')
>>
>> or just
>>
>>     str_cmp("foobar",'trim_whitespace')
>>
>> as the result?
>>
> As long as we are converting I think I prefer
>           str_cmp("foobar", filters=>['trim_whitespace'])
>
> since there will be examples where more than one filter is needed.  
> The default
> is actually
>
> 'filters'               =>  [qw(trim_whitespace compress_whitespace 
> ignore_case)]
>
> str_cmp will accept a variable as if it were an array with one 
> element, but as a model
> I suggest we use the square brackets.
>
> I do want to use the    filters => .....    however.  I think the 
> model of
>
> ans_evaluator( var or arrayRef,   %options)
>
> is something that we can make fairly universal.  At least I'd like to 
> try.
>
>>> Here are some examples of str_cmp
>>> I found in actual problems:
>>>
>>> ANS( str_cmp( $ml -> ra_correct_ans ) );  # no change needed here
>>
>>
>> right
>>
>>> ANS(std_num_str_cmp($ans, ['N']));         # make sure this is 
>>> handled properly
>>
>>
>> That one should already be handled by the version you have.  It is 
>> converted to
>>
>>     ANS(num_cmp($ans, strings=>['N']));
>>
>> which is what you want, right?
>>
> That's correct.
>
>> I'll send an updated version when I know how to handle the 'type' 
>> flag above.
>>
>> Davide
>>
> Thanks.
>
> Take care,
>
> Mike
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> OpenWeBWorK-Devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openwebwork-devel