** Using WeBWorK **

More problems with the v. 1.6xx versions of PGanswermacros.pl have surfaced, with function_cmp _up_to_constant(). This problem occurs both with the v1.601 distribution version and patched version (correcting the (-1)^.5 problem) that Mike sent me last week.

Reverting to the v. 1.5 PGanswermacros.pl (ie. PGanswermacros.pl.original) fixes this problem.

Briefly the student is entering the correct answer:

(1/9)asin(9x/5)

which is being checked via

&ANS(function_cmp_up_to_constant("arcsin($bb*x/$aa)/$bb","x",0,$aa/$bb));

where $bb=9 and $aa=5 and the WeBWorK response is

error: Can't take sqrt of -1.77636e-15. error: Can't take sqrt of -1.77636e-15. The above answer is NOT correct.

The last two parameters to function_cmp_up_to_constant() are supposed to insure that the values of x being plugged into asin((9/5)x) are between 0 and 5/9, which should give real values. But it appears that WeBWorK is plugging in some value outside this range.

Zig

<| Post or View Comments |>

This appears to be a round-off error problem. Whenever one sees a number as small as -1.77636e-15, round-off error is almost always the problem.

To avoid situations like this one, always give webwork an evaluation interval that is a proper subinterval of the mathematical domain of the function. Always stay at least epsilon away from an actual endpoint of the mathematical domain, where epsilon is on the order of 0.001 or 0.0001.

Please try changing your code to &ANS(function_cmp_up_to_constant("arcsin($bb*x/$aa)/$bb","x",0,$aa/$bb-0.001));

Sincerely,

William Wheeler

<| Post or View Comments |>

If this is not the case, and the default evaluation interval is the CLOSED interval [0,1], then it seems to me that there are lots of buggy problems in the problem library shipped with the WeBWorK distribution. For instance problem 1 of set Derivatives6InverseTrig has the following code:

$funct1 = "$a1*$r1*x**($r1-1)*(1-x**(2*$r1))**-.5";

TEXT(EV2(<<EOT));

If ( f(x) = $a1 arcsin(x^{$r1}) ), find ( f'( x ) ).

$BR $BR {ans_rule(50) } $BR

EOT

$ans = $funct1;

&ANS(function_cmp($ans));

which could cause exactly the same sort of trouble as my problem.

Zig

<| Post or View Comments |>

As best I can determine this is a round off error problem. It took me quite a while to find a seed that would reproduce the error.

asin(9x/5) is calculated as atan(sqrt(1-(9x/5)^2). and for one of the random values in the guilty problem x = .5555555555555555555555556

I think the best action here is to take the domain for evaluation as [0, $aa/$bb- .0000001]. When I did that, even with 10,000 points being chosen at random, I didn't have a problem. Possibly the reason things worked in old version 1.5 is that the pseudo-random number generators aren't generating exactly the same random numbers, but I haven't verified that.

I think action on the part of the problem writer is the best solution here. There are times when you want the random number generator to choose numbers right to the end of a closed interval-- (this can be important if you re dealing with integer inputs, or half-integers or some other small denominator rational number) and other times you don't (as here, where round off error might be anticipated to cause problems.)

Hope this helps.

Take care,

Mike

<| Post or View Comments |>

Here are the defaults (as given in Global.pm) that WeBWorK is shipped with. The defined interval is [.0000001,1] which was done on purpose. This is (or at least was in the original code which I doubt Mike has changed in the recent updates --- IMPORTANT ---Mike has changed this, see the next message!) combined with rand(1) which gives a random number in [0,1). So the actual default interval in the old code is [.0000001,1) which we consider (0,1). However, I agree with Mike that you should be careful about possible floating point errors at the endpoints. Note that we have been using [.0000001,1) for years with good results. Also in the original documentation for PGanswermacros.pl I remember writing that the interval you enter is a half open interval [a,b) but I'm not sure that has survived all the updates to the documentation.

Arnie

# The following effect function comparison
...
$functLLimitDefault = .0000001;
$functULimitDefault = 1;

<| Post or View Comments |>

Zig, I think you are correct. Mike did change the code from using rand(1) to using essentially random(0,1,.01) (with random being WeBWorK's random, not Perl's rand) and this gives a random number from the list 0, .01, ..., .99, 1 rather than a random floating point number in the range [0,1). So now there is a closed interval and a rather high probability of hiting an endpoint.

Here's the code:

my $random_for_answers = new PGrandom $main::PG_original_problemSeed);
...
$vars[$i] = $random_for_answers->random($limits[$i][0], $limits[$i][1], abs($limits[$i][1] - $limits[$i][0])/100 );

assuming I'm looking at the correct piece of the code.

I'm not certain at this point how best to fix it so people do not have the bugs you have encountered. I'll let Mike think about this. Some possibilities are changing the code in PGanswermacros.pl so that it behaves like the original and changing the default in Global.pm from $functULimitDefault = 1; to $functULimitDefault = .9999999; (but this wouldn't fix your bug). Whatever we do the documentation needs to reflect this. As you mention, if we keep things as they are, this will cause bugs in the distributed problems. Changing $functULimitDefault = .9999999; will fix all the bugs except where people define their own limits.

As at temporary fix I have reset $functULimitDefault = .9999999; in Global.pm at Rochester

Arnie

<| Post or View Comments |>

Arnie's summary of the changes in PGanswermacros.pl is exactly right. My changes inadvertantly changed the behavior from half open intervals to closed intervals. (As Arnie points out the half open interval had been compensated for, at least in the default parameters.)

From the comments so far, it seems that the most natural assumption is that the function will be evaluated on an open interval. I have a new version of PGanswermacros.pl, moderately tested, although obviously not yet tested by hundreds of students, which chooses points uniformly in the interval [lower_.limit, upper_limit] with step size (upper_limit - lower_limit)/1000. If the upper or lower limit is chosen then it is thrown out.

Are there any comments about this solution? Is there some advantage to making the step size different, or allowing it to be set on a site by site basis?

Thanks for all of the reports. I apologize for breaking the expected behavior on the earlier problems.

Take care,

Mike

<| Post or View Comments |>