** Using WeBWorK **

> Compiler warnings: > * Use of uninitialized value in join at (eval 111) line 2406.

in a problem using multivar_function_cmp when the student's attempt contains variables other than those expected by WW.

<| Post or View Comments |>

One other point. Try using fun_cmp() (see manpages). This is a newer version of the multivariable_function_cmp and may have the bugs fixed.

-- Mike

<| Post or View Comments |>

So:  a student tries an answer using c instead of C and gets
it wrong.  Later, student comes back to the problem and sees a
pink screen with a compiler error at the bottom.

## Description
## First order ODE with xy
## EndDescription

DOCUMENT();
loadMacros(PG.pl,
PGbasicmacros.pl,
PGchoicemacros.pl,
PGanswermacros.pl,
PGauxiliaryFunctions.pl,
PGgraphmacros.pl,
"Dartmouthmacros.pl");

## Do NOT show partial correct answers
$showPartialCorrectAnswers = 0;

## Generate some coefficients
$m = non_zero_random(-6,6,1);

## Clean up stuff like -1 x
$func = clean_scalar_string($m, "xy");

## Ok, we are ready to begin...
##
TEXT(beginproblem());

BEGIN_TEXT
$BR
Solve the following first-order differential equation:
\( \displaystyle frac {dy}{dx} = $func \).
\break
Simplify your answer $BBOLD completely$EBOLD. Your answer should look
like \(y = f(x)\).
\break
If an arbitrary constant appears in your answer, you must enter it as an
uppercase C.
\break
For example, a valid answer for the differential equation \( \frac{dy}{dx}
= y \)
would look like \( C e^x \).
$BR
\( y = \)
\{ ans_rule(40) \}
$PAR

END_TEXT

## The answer is

ANS(multivar_function_cmp("C*e**( $m * {x**2/2})",["x","C"]));

ENDDOCUMENT();

Susan J. Diesel

Hi Susan,

There are a number of possible solutions to this problem.

One would be to make the answer evaluator smarter, so for example variables named C and c are equivalent.

We're working on making it easier to make small changes to existing answer evaluators to handle situations such as this one.

A different way to ask the question is to use fun_cmp() and have the student give a specific solution, (but the instructor gives a general solution which adapts itself to the students answer) see the params option and examples in fun_cmp. I wrote fun_cmp to handle this type of question, but it may not be the question you wanted to ask.

I'll keep thinking to see if there is a cleverer way to handle this problem.

One other question -- does your use of \break display properly in tth mode? and if so how do you accomplish this? ($BR also gives a line break.)

-- Mike

<| Post or View Comments |>

I'm using PGanswermacros.pl.old in WeBWorK 1.6, which I understand are the old WeBWorK 1.5 version. This problem works fine with those old answer macros.

>>> A different way to ask the question is to use fun_cmp() and have the student give a specific solution, (but the instructor gives a general solution which adapts itself to the students answer) see the params option and examples in fun_cmp. I wrote fun_cmp to handle this type of question, but it may not be the question you wanted to ask. <<<

This approach doesn't work very well in the WeBWorK 1.6 version of function_cmp_up_to_constant(), as compared to the old 1.5 version of this routine.

Zig Fiedorowicz

<| Post or View Comments |>

I'm not sure I understand your comment. I don't believe that any of the WeBWorK 1.5 versions will check an answer up to the addition a multiple of a function (such as e^x). Only checking functions 'defined up to a constant' was available and allowed the checking of general solutions to anti-derivatives.

Even in that case I believe that one asked something like:

" Find an anti-derivative of x^2 "

and the answers could be x^3/3 or x^3/3 +456 but NOT x^3/3 + C

Perhaps I'm not thinking of the right sort of example.

-- Mike

<| Post or View Comments |>

You misunderstand. I'm not commenting on the specific format of the answers accepted by various answer evaluators. I was making a general comment about the difference in reliability between the version 1.5 and version 1.6 answer evaluators.

My point was that I find the version 1.5 evaluators much more reliable. I found that the version 1.6 evaluators are unaccceptably tolerant of wrong answers. For instance, I found that (logging in as a practice user) in a great majority of indefinite integration problems in Rochester's own spring courses, I could enter nonsensical answers and have them accepted as correct (without much effort on my part). Susan's trouble with multivar_function_cmp seems to be another example of lesser reliability of a version 1.6 evaluator vis-a-vis the 1.5 version.

I am concerned that the "adaption algorithm" you seem to be using in the version 1.6 evaluators has some inherent flaws as compared to the more straightforward algorithms you were using in previous versions.

Zig

<| Post or View Comments |>

I think I understand now. The original version 1.6 had some difficulties because they adapted the instructor's answer to the student's, allowing the student to spoof correct answers by adding large constants that drowned out the differences between the student answer and the professor's (particularly when using the relative tolerance option).

Now the student's answer is adapted to the professor. This still leaves some ambiguity when using relative accuracy for indefinite integrals, since the actual accuracy required will depend on the answer entered by the professor. e.g. entering x^2 + 10000000 + c will allow quite a bit of actual error, although relative to the professor's answer with c=0 the error will be small. One could argue that relative accuracy should never be used for anti-derivatives since they are not well defined and the student cannot deduce how accurate his answer must be to guarantee 1% relative accuracy with respect to the instructor's answer. That's probably quibbling however since the current setup (and the one in version 1.5) seem to work pretty well in practice, even using relative accuracies.

I'd be interested in knowing if any of the problems which gave false positive answers still have that problem under the new system. You can check any of the UR problems (including many which you contributed from the OSU collection) using the newest macros from the URL:

http://webhost.math.rochester.edu/webworkdocs/ww/listLib?command=setsOnly

We've checked a lot, but it's difficult to check everything. When checking answers to differential equations, where the answer is checked up to a linear combination of exponentials, one still has to be somewhat careful about choosing the domain properly in order to avoid numerical problems when the exponential function is either way too large or way too small. With anti-derivatives I don't anticipate any such problems however.

Thanks for the help and the comments.

-- Mike

<| Post or View Comments |>