Difference between revisions of "DigitsTolType"

From WeBWorK_wiki
Jump to navigation Jump to search
(add note about relative tolerance)
 
(2 intermediate revisions by the same user not shown)
Line 73: Line 73:
 
<p>
 
<p>
 
<b>Warning:</b> this tolerance type also applies to formula comparisons. For example if the answer is 2^x and a student enters e^(0.69x), this will probably not be accepted. Random test values will be used for x to make that comparison. For example if one of the test values is x=2, the correct output is 4 and the student's output would be 3.9749... and this would be declared as not a match, since the first three digits to not agree.
 
<b>Warning:</b> this tolerance type also applies to formula comparisons. For example if the answer is 2^x and a student enters e^(0.69x), this will probably not be accepted. Random test values will be used for x to make that comparison. For example if one of the test values is x=2, the correct output is 4 and the student's output would be 3.9749... and this would be declared as not a match, since the first three digits to not agree.
  +
</p>
  +
<p>
  +
<b>Warning:</b> this article is about using this tolerance type for comparison of correct answers to student answers. But if this tolerance type is activated for a context, it also applies to comparisons you might make in problem setup code. It may be important to understand that it is not symmetric. For example, under default conditions, <code>Real(4) == Real(3.995)</code> is false, while <code>Real(3.995) == Real(4)</code> is true. The left operand is viewed as the "correct" value. With <code>Real(4) == Real(3.995)</code>, that "5" violates the <code>tolExtraDigits</code> checking. But with <code>Real(3.995) == Real(4)</code>, it is as if the student entered 4.00 and has the first 3 digits correct accounting for rounding. (Note that the default tolerance type <code>relative</code> is similarly asymmetric, but the effect is more subtle. You can see it with <code>Real(4) == Real(3.996001)</code> versus <code>Real(3.996001) == Real(4)</code>.)
 
</p>
 
</p>
   

Latest revision as of 15:05, 30 April 2021

Construction.png This article is under construction. Use the information herein with caution until this message is removed.

Digits TolType


This describes an alternative way for determining the tolerance type based on the number of digits.

Problem Techniques Index

PG problem file Explanation
DOCUMENT();
loadMacros(
  "PGstandard.pl",
  "MathObjects.pl",
  "PGML.pl"
);
TEXT(beginproblem());

Initialization: The tolType of type digits is built-in to MathObjects.

Context("Numeric")
Context()->flags->set(tolType => 'digits', tolerance => 3, tolTruncation => 1);
$answer = Real("pi");

Setup:

  • The tolType => 'digits' switches from the default 'relative' tolerance type to the 'digits' tolerance type.
  • The tolerance => 3 sets the number of digits to check to 3. The default value is acutally the default for other tolerance types, 0.001, but any tolerance that is between 0 and 1 is converted via log10 and rounding to an integer (in this case, to 3).
  • The tolTruncation parameter is either 1 (true) or 0 (false). Its default is 1. Details are explained below.
  • The tolExtraDigits parameter sets the number of extra digits to examine beyond the first tolerance digits. Its default value is 1. This is explained below.

The goal is that the student must enter at least the first tolerance digits correctly. The last digits that they enter might be rounded (always accepted) or truncated (only accepted if tolTruncation is true). For example, if the correct answer is e=2.7182818... and tolerance is 3, the student can answer with 2.72. Or they can answer with 2.71 if tolTruncation is true. But for example 2.7 and 2.73 are not accepted.

If the student enters additional digits, the first additional tolExtraDigits digits are examined in the same manner. For example, if the correct answer is pi=3.1415926... and default flag values are used, the student can answer with 3.14, 3.141, 3.142, 3.1415, and even 3.1418 since that 8 is beyond the extra digits checking. But for example 3.143 is not accepted, since the first extra digit is not right. (And if tolTruncation is false, 3.141 would not be accepted either.)

Warning: this tolerance type also applies to formula comparisons. For example if the answer is 2^x and a student enters e^(0.69x), this will probably not be accepted. Random test values will be used for x to make that comparison. For example if one of the test values is x=2, the correct output is 4 and the student's output would be 3.9749... and this would be declared as not a match, since the first three digits to not agree.

Warning: this article is about using this tolerance type for comparison of correct answers to student answers. But if this tolerance type is activated for a context, it also applies to comparisons you might make in problem setup code. It may be important to understand that it is not symmetric. For example, under default conditions, Real(4) == Real(3.995) is false, while Real(3.995) == Real(4) is true. The left operand is viewed as the "correct" value. With Real(4) == Real(3.995), that "5" violates the tolExtraDigits checking. But with Real(3.995) == Real(4), it is as if the student entered 4.00 and has the first 3 digits correct accounting for rounding. (Note that the default tolerance type relative is similarly asymmetric, but the effect is more subtle. You can see it with Real(4) == Real(3.996001) versus Real(3.996001) == Real(4).)

BEGIN_PGML

This section is with [|tolTruncation|] set to true (1).  The exact answer is [`\pi`].   Enter 3.14, 3.15, 3.141, 3.142 to see if it accepts the answer.  

[`\pi=`][_]{$answer}

END_PGML

First Section: This tests the default conditions for this tolerance type. It should accept 3.14, 3.141 and 3.142 as correct, but not 3.15.


Context("Numeric");
Context()->flags->set(tolType => 'digits', tolerance => 3, tolTruncation => 0);
$answer2 = Real("pi");

Second block explanation: First, reset the context with Context("Numeric") and then the same flags are set as before except for tolTruncation => 0.

BEGIN_PGML
This section is with [|tolTruncation|] set to false (0).  The exact answer is [`\pi`].   Enter 3.14, 3.141, 3.142 to see if it accepts the answer. 

[`\pi=`][_]{$answer2}

END_PGML

Second Section: This tests when tolTruncation is false. It should accept 3.14, 3.142 as correct, but not 3.141.

Context("Numeric");
Context()->flags->set(tolType => 'digits', tolerance => 3, tolTruncation => 0, tolExtraDigits => 2);
$answer3 = Real("3.14");

Second block explanation: First, reset the context with Context("Numeric") and then the same flags are set except for tolTruncation => 0 as well as the tolExtraDigits => 2.

BEGIN_PGML

This section is with [|tolTruncation|] set to false (0) and [|tolExtraDigits|] set to 2. Enter 3.1415, 3.1416, 3.1417, 3.14888, 3.14, and 3.1415888 to see if it accepts the answer. 

[`\pi=`][_]{$answer3}

END_PGML

Third Section: This additionally tests when tolExtraDigits is larger than its default. It should accept 3.1416, 3.14, and 3.1415888. It should reject 3.1415 because tolTruncation is false. It should reject 3.1417 and 3.14888 because the student chose to use extra digits and the first two of those are not correct.

Problem Techniques Index