** Using WeBWorK **

Thank you for your help!

-Barbra Bannon

<| Post or View Comments |>

Zig Fiedorowicz

#DESCRIPTION

#Simplify expression involving trig and inverse trig functions

#ENDDESCRIPTION

#KEYWORDS('Trigonometric Functions', 'Inverse Functions')

DOCUMENT();

loadMacros(

PG.pl,

PGbasicmacros.pl,

PGchoicemacros.pl,

PGanswermacros.pl,

PGauxiliaryFunctions.pl );

$showPartialCorrectAnswers = 1;

$a = random(3,6,1);

TEXT(&beginproblem);

TEXT(EV2(<<{first_answer};));>));>

$firstAnswer = '' unless defined($firstAnswer);

if (($firstAnswer =~ /tan/) || ($firstAnswer =~ /cos/) || ($firstAnswer =~ /sin/))

{NAMED_ANS(first_answer,strict_str_cmp("2*x*sqrt($a^2-x^2)/(2*x^2-$a^2)"));}

else

{NAMED_ANS(first_answer,function_cmp("2*x*sqrt($a^2-x^2)/

(2*x^2-$a^2)"));}

ENDDOCUMENT();

<| Post or View Comments |>

>x(x-i)(x+i)(x-(2^(1/2))i)(x+(2^(1/2))i)

I don't believe WeBWorK currently supports complex expressions. If you wanted to do this, you would need to modify WeBWorK's parser.

Zig Fiedorowicz

<| Post or View Comments |>

First, it would not be hard to make a generic answer evaluator which takes a list of answer evaluators and credit weights:

[[ev1, wt1], [ev2, wt2], ...]

The new evaluator would try each ev in turn until it hit one which gives positive credit, and then multiplies that value by the wt and stops. If no ev gives a positive response, the student simply gets the problem wrong.

I haven't written this yet, but it would not be hard. People can respond to say if they think this would be a generally useful addition to WW.

The next piece is a specialized answer evaluator for dealing with factored answers. It would have to parse the student's response, break it up as a product, and match the pieces in different orders to the pieces the teacher supplies. This piece is also not terribly hard, but it seems like a shame to write another parser when WebWork has one already. I would rather see the current parser modified (possibly broken into more modular pieces) so that it could handle the task. Again, I would be interested in comments.

John Jones

<| Post or View Comments |>

I'm not sure this would be that simple. The PG language currently fineses the problem of determining whether two expressions are equivalent by using numerical checking rather than symantic comparisons. Roughly speaking two functions are "equivalent" if they produce the same output at 5 randomly selected inputs. This works surprisingly well, although for certain types of answers one has to be careful about the domain and about round-off error.

By this rule, x^2+2x+1 and (x+1)^2 are indistinguishable (which is often what you want).

Checking the answer by pattern matching could get somewhat involved. For example (x +1)(x+1), (x+1)^2, (1+x)(1+x), (x+1)(1+x), ((cos(x)^2+(sin(x))^2 +x)^2 are all correct answers. It seems to me that trying to catch all of these soon leads you to reinventing Mathematica or Maple, not just the PG language parser.

It is feasible to write an answer evaluator which calls Maple or Mathematica from within perl to check whether two expressions are equivalent, but I'm not sure that even Maple would recognize the last example above as correct. Calling Maple or Mathematica would also be a pretty hefty use of computing resources.

Breaking the parser into more manageable pieces, or allowing it to be customized more easily, is a good idea in any case, but it will take some time to implement. Bill Wheeler at Indiana University has made some progress in this direction.

-- Mike

<| Post or View Comments |>

A better way would be if parsing produced a semi-digested form of the expression. For example, if the expression is represented by a tree (in the more or less standard way), then the top node of the tree gives the last operation performed when evaluating the expression. In a factorization problem, this has to be *, ^, or /. From there, you can work down the tree to produce the list of factors. Then there is the matching problem -- is one unordered list the same as a second unordered list. To test if two factors are the same, one would use WeBWork's function comparison (via testing points). This approach would even manage to see that the crazy answer is correct.

The new pieces needed to make this work would be: parse an expression into a tree; take the tree and produce a list of factors; possibly something which calls the function comparison evaluator in a way which is conducive to being part of a bigger evaluator (maybe it is fine as is).

John

<| Post or View Comments |>