** Using WeBWorK **

Alex:

There is another file called parserCustomization.pl that might be better for this. It is loaded automatically when MathObjects.pl is loaded, so you don't have to worry about whether PGcourse.pl is used or not. So make a file called parserCustomization.pl in your templates/macros folder in order to make course-wide customizations.

I can think of two ways to do what you want, though neither is ideal. The first is to add

foreach my $name (keys %Parser::Context::Default::context) {
  $context{$name} = Parser::Context->getCopy($name);
  $context{$name}->flags->set(tolerance => .01);
}
Context("Numeric");

to your parserCustomization.pl file. This will create a local copy of all the predefined contexts with the new tolerance, and these will be used in preference to the default ones whenever one is loaded via Context() or accessed in any other way. This means that any other contexts that are loaded later (such as those defined in files like contextInequalities.pl) will inherit the changes you made, since all these macro files copy an existing context and modify it (as I recall). This also means that the traditional checkers (like num_cmp()), which use MathObjects behind the scenes, will also use the new tolerance, provided the problem they are in loads MathObejcts.pl.

The main drawback here is that, since this is done for each problem individually every time it is run, and for every context that is predefined (there are 21), that can be a lot of overhead copying contexts that aren't used. There is also the issue that not all problems that use the traditional checkers like num_cmp will load MathObejcts.pl, but you could add

loadMacros("MathObjects.pl");

to your PGcourse.pl file an perhaps pick up some are of those, if that is ends up being a problem.

The other way would be to add

PG_restricted_eval(<<'END');
sub Context {
  my $context = Parser::Context->current(\%context,@_);
  $context->flags->set(tolerance => .01) if scalar(@_);
  return $context;
}
END
Context("Numeric");

to your parserCustomization.pl file. This overrides the Context() function so that only the contexts that you actually use would be modified (so less overhead). The PG_restricted_eval() is there to prevent error messages about redefining an existing macro (I think this will prevent them from appearing in the server log as well, but I'm not sure of that).

The issue here is that This only works when Context() is called explicitly, and so if a context is acquired by other means (e.g., by copying an existing one), that means it won't get modified. Most of the macro files that create contexts do so by copying without setting them directly, but since you eventually do use Context() to enable them, that should not be a problem. But the traditional num_cmp() and friends never call Context() (they use a lower-level call), the contexts they use would not be modified.

So those are the two ways I can see to accomplish what you want. Try them out and see if one works for you.

Davide

There is a setting under Course Configuration -> PG - Problem Display/Answer Checking: