## WeBWorK Problems

### How to make an answer an Union of intervals where one interval is a singleton? ### How to make an answer an Union of intervals where one interval is a singleton?

by Jan Hlavacek -
Number of replies: 2

I am trying to write a problem where the answer is supposed to be a union of intervals with one of the intervals being a singleton. The problem is a bit more complicated, the intervals are randomly generated, but basically I do this:

DOCUMENT();

"PGstandard.pl",
"MathObjects.pl",
"PGcourse.pl",
"PGML.pl",
"PGgraphmacros.pl",
"PGchoicemacros.pl",
);

TEXT(beginproblem());

$i1 = Interval("(-Infinity,-2)");$i2 = Interval("(-2,1]"); $i3 = Interval("{3}");$i4 = Interval("[4,5));

$answer = Union($i1, $i2,$i3, $i4); BEGIN_PGML Blah blah instruction Answer: [_______________________]{$answer}
END_PGML

BEGIN_PGML_SOLUTION
Blah blah the answer is [ [$answer] ]. END_PGML_SOLUTION  In the solution, the answer is displayed correctly, but when I try to enter the answer, I get "Operands of 'U' must be intervals or sets", with the 'U' immediately preceding the '{3}' highlighted. I tried to enter [3,3] instead of {3}, and it works, but in answer help for Interval, it specifically says that "When an interval contains only one point, enter it as a one point set such as {3} or as a closed interval such as [3,3]." It seems like only the [3,3] notation works. Is there any flag I can set to make the answer checker accept the {3} notation as well? In reply to Jan Hlavacek ### Re: How to make an answer an Union of intervals where one interval is a singleton? by Davide Cervone - You need to specify that you are using the Interval context by adding  Context("Interval");  before you define the intervals and unions. By default, you get Numeric context, in that context, {3} is just the number three, not a set. (Braces and brackets act as parentheses in Numeric context). You might be better off using $answer = Compute("(-inf,-2) U (-2,1] U {3} U [4,5)");

rather than using Union() and Interval() directly, as these will produce results even in contexts where students can't type them, as in your case. The Compute() approach should only process things that the student can actually type.

The U operator should probably be disabled in the Numeric context, so that you don't run into these sorts of issues. 