** Using WeBWorK **

There are, in fact, several issues that are causing the problems you are facing.

The first is that you are not actually passing the objects that you think you are to the PGML answer checkers. When you use an answer of the form

     [_________]{[$f]}

you are not passing $f as the answer, but rather you are asking for the string version of $f and that is then passed to Compute() to generate a new MathObject. The newly computed object doesn't have the test_points set, and so it reverts to the usual test points, which are not at integer values, and so the factorial is not defined for them.

The reason you get a new object rather than the original is because of the brackets around $f. Had you used

    [_________]{$f}

instead, you would have gotten the object you intended to use, which is the one that has the test_points set.

But there is still another problem. For MathObjects, a student can provide an answer that includes any of the variables in the Context, and so your test_points must include values for all the variables that are defined, not just the ones used in your formula.

Since you have used variables->add() to add k and n, these are in addition to the original x and so you need to include values for all three of those variables in your points, not just one or two.

Had you used

    Context()->variables->are(
      k => 'Real',
      n => 'Real',
    );

instead, there would only have been two variables, and you could use test points with only two coordinates.

I think making those changes should make it work for you.

The reason it worked when the formula doesn't include factorials is that the other operations don't require integer values, and so not having the test_points that you defined doesn't hurt the check. Only with the factorial was that an issue.

Davide

An alternative approach would be to not specify the the test_points directly, but to set the limits and resolution of the variables themselves so that the random point algorithm always selects integer values.

For example

    Context()->variables->are(
      k => ['Real', limits=>[1,10], resolution=>1],
      n => ['Real', limits=>[1,10], resolution=>1],
    );

would define k and n so that they only take on integer values between 1 and 10. I don't think the random point generator prevents duplicate points, so with this small number of possibilities, it is likely that some integers may be used more than once, so there is some possibility that only a single value will actually be checked.

Note that this means you don't have to specify any test_points, and it is not affected by the presence of other variables in the Context, so your PGML would have worked if this approach had been used.

Davide