Difference between revisions of "FormulaTestPoints"
m 
(Add explanatory remarks, including a warning about cube roots) 

(18 intermediate revisions by 7 users not shown)  
Line 1:  Line 1:  
+  When the solution to a problem is a formula, WeBWorK compares student answers to the given solution by evaluating them at a set of randomly chosen test points. If for all test points, neither the correct answer nor the student's evaluate to anything, an error "Can't generate enough valid points for comparison" is signaled. Thus, it is important that the test points be chosen from an interval contained in the domain of the correct answer. For instance, if a Real variable is going to have its logarithm taken, or raised to a noninteger power, then it should always be positive (<b>NB:</b> even <i>rational exponents with odd denominator</i> such as cube roots, which mathematically apply unproblematically to negative numbers, should have their domains restricted to positive numbers, since floatingpoint arithmetic is not reliable about being able to do such computations.) The default range from which these points are chosen is 2 to 2 for MathObjects (and 1 to 1 for the traditional checkers); this page explains how to change it. 

+  
<h2>Formula Test Points for Evaluation: PG Code Snippet</h2> 
<h2>Formula Test Points for Evaluation: PG Code Snippet</h2> 

Line 7:  Line 9:  
<p> 
<p> 

This can, of course, be done with new and oldstyle answer evaluators. An example of the latter appears below. Also note that we may want to do this in two different ways: either by setting the <em>domain</em> on which the formula is evaluated (that is, the <em>limits of evaluation</em>), or by setting specific <em>test points</em> on which the formula should be considered. These are both shown below. 
This can, of course, be done with new and oldstyle answer evaluators. An example of the latter appears below. Also note that we may want to do this in two different ways: either by setting the <em>domain</em> on which the formula is evaluated (that is, the <em>limits of evaluation</em>), or by setting specific <em>test points</em> on which the formula should be considered. These are both shown below. 

+  </p> 

+  
+  <p style="textalign:center;"> 

+  [[Problem_TechniquesProblem Techniques Index]] 

</p> 
</p> 

Line 17:  Line 23:  
<td style="backgroundcolor:#ffffdd;border:black 1px dashed;"> 
<td style="backgroundcolor:#ffffdd;border:black 1px dashed;"> 

<pre> 
<pre> 

−  Context()>variables>set(x=>{limits=>[1,1]}); 

+  Context("Numeric"); 

−  $func = Compute("sqrt(x+1)"); 

+  Context()>variables>set(x=>{limits=>[1,1]}); 

+  $func = Compute("sqrt(x+1)"); 

−  +  ## Alternately: 

−  +  Context()>flags>set(limits=>[2,5]); 

−  +  # $func = Compute("sqrt(x1)"); 

−  +  ## Or, setting the limits only for the given 

−  +  ## formula, we don't need to reset the Context, 

−  +  ## and just include 

−  +  # $func = Compute("sqrt(x1)"); 

−  +  # $func>{limits} = [2,5]; 

−  +  $gunc = Compute("sqrt(x^2  4)"); 

−  +  $gunc>{test_points} = [[3],[2],[2],[3],[4]]; 

+  #$gunc>{test_at} = [[3],[2],[2],[3],[4]]; 

</pre> 
</pre> 

</td> 
</td> 

<td style="backgroundcolor:#ffffcc;padding:7px;"> 
<td style="backgroundcolor:#ffffcc;padding:7px;"> 

<p> 
<p> 

−  We don't have to change anything in the documentation and tagging or initialization sections of the PG file. In the problem setup, we can specify the limits on which all Formulas are evaluated by setting the <code>limits</code> for the variable in the problem (in this case, <i>x</i>) in the Context. Alternately, we can set the <em>Context flag</em> <code>limits</code> to set the limits on all variables in the Context, as shown in the commentedout line, or can set the limits for the formula itself, as in the second commented 
+  We don't have to change anything in the documentation and tagging or initialization sections of the PG file. In the problem setup, we can specify the limits on which all Formulas are evaluated by setting the <code>limits</code> for the variable in the problem (in this case, <i>x</i>) in the Context. Alternately, we can set the <em>Context flag</em> <code>limits</code> to set the limits on all variables in the Context, as shown in the commentedout line, or can set the limits for the formula itself, as in the second commentedout line. (Obviously, only one of these three is needed.) 
</p> 
</p> 

<p> 
<p> 

−  It is also possible to specify the actual points on which the Formula will be evaluated. This is an attribute of the Formula itself; the call is shown for our formula <code>$gunc</code>. In this case there is only one variable, so we have only to specify a single value for each point where the function is to be evaluated. 
+  It is also possible to specify the actual points on which the Formula will be evaluated. This is an attribute of the Formula itself; the call is shown for our formula <code>$gunc</code>. In this case there is only one variable, so we have only to specify a single value for each point where the function is to be evaluated. 
+  (Using <code>test_at</code> adds the specified points to those already chosen from the continuous domain while with <code>test_points</code> only the specified test points are used.) 

+  If the function were a function of two variables, then we might use something like <code>$formula>{test_points} = [[3,2],[2,0],[2,0],[3,2],[4,5]]</code>. <em>Note that the test points are given in alphabetical order by variable name! Thus, if the variables in the formula are specified as x and C, the test point [3,2] is C=3 and x=2.</em> 

</p> 
</p> 

<p> 
<p> 

−  One final note: if the formula is a function of more than one variable and we're specifying limits in the formula, we need to specify the limits for all variables. Thus, we'd have something like <code>$formula>{limits} = [[1,1],[0,2]]</code>. Again, the limits are specified for each variable in alphabetical order. 

+  It is possible to test at points that are not defined in the correct solution (e.g., to verify that a student didn't enter <code>ln(x)</code> instead of <code>ln(x)</code>). To avoid having this throw an error, however, we must tell the formula that it's allowed by setting <code>$gunc>{allowUndefinedPoints} = 1</code>. 

+  </p> 

+  <p> 

+  Note: if the formula is a function of more than one variable and we're specifying limits in the formula, we need to specify the limits for all variables. Thus, we'd have something like <code>$formula>{limits} = [[1,1],[0,2]]</code>. Again, the limits are specified for each variable in alphabetical order. 

+  </p> 

+  <p> 

+  Also note that your test points must contain one value per variable, even if it doesn't appear in the formula; for instance, if <code>$gunc</code> is a function only of y, then you still need to include values for x <em>and</em> y, not just y. The alternative is to use the command 

+  <code>Context() > variables > are (y => 'Real')</code> early in your .pg file, which will remove the (default) variable x from the problem. 

+  </p> 

+  <p> 

+  If you are trying to set test points for a function you have added to the context (e.g., using <code>parserFunction.pl</code>) you should use the syntax <code>$h>with(test_at=>[[1],[2]])</code> as in the following code snippet: 

+  <pre> 

+  loadMacros("parserFunction.pl"); 

+  
+  Context("Numeric"); 

+  parserFunction("m(x)" => "log(x/2)" ); 

+  $h = Formula("5 m(x)+2"); 

+  $answer = $h>with(test_at => [[1],[2]]); 

+  </pre> 

+  </p> 

+  <p> 

+  If you want to add a variable <code>n</code> to the context that is only evaluated at integers, use integer limits and a resolution of 1 as in the following example: 

+  <pre> 

+  Context()>variables>add(n => ['Real', limits=>[1,20], 

+  resolution=>1]); 

+  </pre> 

</p> 
</p> 

</td> 
</td> 

Line 49:  Line 81:  
<td style="backgroundcolor:#ffdddd;border:black 1px dashed;"> 
<td style="backgroundcolor:#ffdddd;border:black 1px dashed;"> 

<pre> 
<pre> 

−  +  BEGIN_TEXT 

−  +  Enter \( $func \): \{ ans_rule(35) \} 

−  +  $BR 

−  +  Enter \( $gunc \): \{ ans_rule(35) \} 

−  +  END_TEXT 

</pre> 
</pre> 

<td style="backgroundcolor:#ffcccc;padding:7px;"> 
<td style="backgroundcolor:#ffcccc;padding:7px;"> 

Line 64:  Line 96:  
<td style="backgroundcolor:#eeddff;border:black 1px dashed;"> 
<td style="backgroundcolor:#eeddff;border:black 1px dashed;"> 

<pre> 
<pre> 

−  +  ANS( $func>cmp() ); 

−  +  ANS( $gunc>cmp() ); 

</pre> 
</pre> 

<td style="backgroundcolor:#eeccff;padding:7px;"> 
<td style="backgroundcolor:#eeccff;padding:7px;"> 

Line 126:  Line 158:  
</tr> 
</tr> 

</table> 
</table> 

+  <p style="textalign:center;"> 

+  [[IndexOfProblemTechniquesProblem Techniques Index]] 

+  </p> 

+  
+  [[Category:Problem Techniques]] 
Latest revision as of 10:55, 4 March 2016
When the solution to a problem is a formula, WeBWorK compares student answers to the given solution by evaluating them at a set of randomly chosen test points. If for all test points, neither the correct answer nor the student's evaluate to anything, an error "Can't generate enough valid points for comparison" is signaled. Thus, it is important that the test points be chosen from an interval contained in the domain of the correct answer. For instance, if a Real variable is going to have its logarithm taken, or raised to a noninteger power, then it should always be positive (NB: even rational exponents with odd denominator such as cube roots, which mathematically apply unproblematically to negative numbers, should have their domains restricted to positive numbers, since floatingpoint arithmetic is not reliable about being able to do such computations.) The default range from which these points are chosen is 2 to 2 for MathObjects (and 1 to 1 for the traditional checkers); this page explains how to change it.
Formula Test Points for Evaluation: PG Code Snippet
This code snippet shows the essential PG code to specify the points on which a formula is evaluated when a student's answer is checked. Note that these are insertions, not a complete PG file. This code will have to be incorporated into the problem file on which you are working.
This can, of course, be done with new and oldstyle answer evaluators. An example of the latter appears below. Also note that we may want to do this in two different ways: either by setting the domain on which the formula is evaluated (that is, the limits of evaluation), or by setting specific test points on which the formula should be considered. These are both shown below.
PG problem file  Explanation 

Context("Numeric"); Context()>variables>set(x=>{limits=>[1,1]}); $func = Compute("sqrt(x+1)"); ## Alternately: Context()>flags>set(limits=>[2,5]); # $func = Compute("sqrt(x1)"); ## Or, setting the limits only for the given ## formula, we don't need to reset the Context, ## and just include # $func = Compute("sqrt(x1)"); # $func>{limits} = [2,5]; $gunc = Compute("sqrt(x^2  4)"); $gunc>{test_points} = [[3],[2],[2],[3],[4]]; #$gunc>{test_at} = [[3],[2],[2],[3],[4]]; 
We don't have to change anything in the documentation and tagging or initialization sections of the PG file. In the problem setup, we can specify the limits on which all Formulas are evaluated by setting the
It is also possible to specify the actual points on which the Formula will be evaluated. This is an attribute of the Formula itself; the call is shown for our formula
It is possible to test at points that are not defined in the correct solution (e.g., to verify that a student didn't enter
Note: if the formula is a function of more than one variable and we're specifying limits in the formula, we need to specify the limits for all variables. Thus, we'd have something like
Also note that your test points must contain one value per variable, even if it doesn't appear in the formula; for instance, if
If you are trying to set test points for a function you have added to the context (e.g., using loadMacros("parserFunction.pl"); Context("Numeric"); parserFunction("m(x)" => "log(x/2)" ); $h = Formula("5 m(x)+2"); $answer = $h>with(test_at => [[1],[2]]);
If you want to add a variable Context()>variables>add(n => ['Real', limits=>[1,20], resolution=>1]); 
BEGIN_TEXT Enter \( $func \): \{ ans_rule(35) \} $BR Enter \( $gunc \): \{ ans_rule(35) \} END_TEXT 
The text portion of the file is the same as usual. 
ANS( $func>cmp() ); ANS( $gunc>cmp() ); 
And the answer evaluation is as we'd expect. 
With oldstyle answer evaluators, we can do the same thing:
PG problem file  Explanation 

$func = "sqrt(x+1)"; $gunc = "sqrt(x^2  4)"; 
We define the functions as expected in the problem setup section of the file. 
BEGIN_TEXT Enter \( \sqrt{x+1} \): \{ ans_rule(35) \} $BR Enter \( \sqrt{x^2  4} \): \{ ans_rule(35) \} END_TEXT 
And the text portion of the file is similarly mundane. 
ANS(fun_cmp($func, limits=>[1,1])); ANS(fun_cmp($gunc, test_points=>[3,2,2,3,4])); 
The limits or test points are specified in the 