** Using WeBWorK **

No, MathObjects.pl is simply a renaming of Parser.pl (the older name for MathObjects was Parser objects). The name change was made during the summer, so you may not have the new .pl file unless you updated your PG directory since then. You can continue to use Parser.pl for now, or could simply copy pg/macros/Parser.pl to pg/macros/MathObject.pl if you want to begin using the new name.

Davide

Values that are right at the edge of the tolerance are always very touchy. For example, .1 is a repeating decimal in binary notation, so can't be represented exactly, and so 1 - .99 is not exactly .1 when handled in finite-precision binary notation. The numeric issues involved can be quite subtle and counter-intuitive in general. You can't rely on the behavior at the very boundaries of the tolerance setting.

In any case, the tolerance uses a strict inequality, not less-than-or-equal, so even with exact arithmetic, .99 would not match a .1 tolerance.

Finally, the error for .9901 (compared to a correct answer of 1) is .0099, or just under 1% (not the .01% you claim), so this answer is correctly marked, and, together with the answer of .99, does show that the tolerance is correctly set at .01 (or 1%).

Davide

Your answer is below the default limit at which relative tolerance comparisons are automatically switched over to absolute tolerance comparision.

This is usually the desirable behavior, if the answer results in zero for some particular value of the seed, then it is quite possible that round off error will make the instructor's answer a very small number. A student, using a mathematically equivalent but operationally different method of calculating the answer, will have a slightly different round off error and their answer will be marked incorrect -- not what is desired or expected. The errors are small in absolute terms but large relative to the correct answer.

For your problem you want to work with answers that are very small, so the defaults at which the comparison automatically switches from relative to absolute (zeroLevel) needs to be lowered and the absolute comparison with zero (zeroLevelTol) needs to be lowered as well. You can experiment with various settings in the snippet below:

########################################################################
DOCUMENT();
loadMacros(
  "PGstandard.pl", # Standard macros for PG language
  "MathObjects.pl",
  "parserNumberWithUnits.pl",
);

Context()->flags->set(zeroLevel => 1E-50);
Context()->flags->set(zeroLevelTol => 1E-55);

BEGIN_TEXT
zeroLevel \{ Context()->flags->get('zeroLevel')\}
$PAR
zeroLevelTol \{ Context()->flags->get('zeroLevelTol')\}
$PAR
Enter the answer of 1E-23 Newton \{ans_rule()\}
END_TEXT

ANS( NumberWithUnits(1E-23, 'N')->with(tolType=>'relative', tolerance=>.01)->cmp );

ENDDOCUMENT();

If desired the default limits can be reset in global.conf (for the site) or course.conf (for the course), but you should be cautious about setting extreme values for these.

(Edited by Davide Cervone - original submission Tuesday, 18 December 2007, 12:40 PM)

My tests show that

    ANS(NumberWithUnits(8.23E-8,"N")->with(tolerance=>0.03)->cmp);

accepts answers up to 8.476E-8, which is the requires 3%. I suspect that the reason is that your copy of PG needs to be updated. There were a number of important changes this past summer, and one was to fix some problems with passing tolerance values (and other flags) from one object to another. In this case, the NumberWithUnits uses a Real object internally and wasn't passing the flags downward properly. This is working in the current version, so you may want to upgrade.

You can update the PG directory without updating the whole WeBWorK installation, and I would recommend that you do that (after first backing up the PG directory tree in case you decide you need to go back). The current version of PG can be used with WW2.3.2 for sure, and perhaps even earlier.

If you can't update to this version, then you can try using

    ANS(NumberWithUnits(8.23E-8,"N")->cmp(tolerance=>0.03));

instead, and if that doesn't work either, try setting the tolerance in the context itself:

    Context()->flags->set(tolerance=>.03);
    ANS(NumberWithUnits(8.23E-8,"N")->cmp);

though that will affect all numeric comparisons, not just this one.

Davide