I have several problems that ask students to apply a convergence test to a series. As part of the question they select <,>, or = from a popup. The problems where the answer is < do not appear to be working. In the answer preview all I see is a blank. Problems where the correct answer is > or = seem to work fine.
I guess I could just type out less than.
Sample code:
##DESCRIPTION
#
# File Created: 10/30/2008
# Last Modified: 10/30/2008
# Problem Author: Darwyn Cook
# WeBWorK Entry:
# Location: Alfred University
#
##ENDDESCRIPTION
##KEYWORDS('monotonic' 'sequence')
##
## DBsubject('Calculus')
## DBchapter('Infinite Sequences and Series')
## DBsection('Monotonic Sequences')
## Date('10/30/2008')
## Author('Darwyn Cook')
## Institution('Alfred University')
## TitleText1('Calculus: with Early Transcendentals')
## EditionText1('8')
## AuthorText1('Anton')
## Section1('10.2')
## Problem1('')
########################################################################
DOCUMENT();
loadMacros(
"PGstandard.pl", # Standard macros for PG language
"MathObjects.pl",
);
# Print problem number and point value (weight) for the problem
TEXT(beginproblem());
# Show which answers are correct and which ones are incorrect
$showPartialCorrectAnswers = 1;
##############################################################
#
# Setup
#
#
Context("Numeric");
Context()->variables->add(n=>"Real");
Context()->strings->add(">"=>{},"<"=>{},"="=>{},"?"=>{});
Context()->strings->add("monotone decreasing"=>{},"monotone increasing"=>{},"monotone nondecreasing"=>{},"monotone nonincreasing"=>{},"cannot be determined"=>{});
$a = Compute(random(2,10));
$b = random(2,10);
$s = Formula("$b^n/(3*n)!");
$d = Formula("$b/((3*n+3)*(3*n+2)*(3*n+1))");
$question = String("?");
$less = String("<");
$greater = String(">");
$equal = String("=");
$dec = String("monotone decreasing");
$inc = String("monotone increasing");
$nondec = String("monotone nondecreasing");
$noninc = String("monotone nonincreasing");
$cbd = String("cannot be determined");
##############################################################
#
# Text
#
#
Context()->texStrings;
BEGIN_TEXT
We want to determine if the sequence \($s\) is monotonic.
$BR
Using the ratio test we get that \(\frac{s_{n+1}}{s_{n}} = \) \{$d->ans_rule()\}
\{ pop_up_list([$question->string,$equal->string,$greater->string,$less->string]) \} 1
$BR
Hence the sequence is \{ pop_up_list([$question->string,$dec->string,$inc->string,$noninc->string,$nondec->string,$cbd->string]) \}
END_TEXT
Context()->normalStrings;
##############################################################
#
# Answers
#
#Force some simplification:
Context()->operators->remove('-','^','!');
ANS($d->cmp());
ANS($less->cmp());
ANS($dec->cmp());
ENDDOCUMENT();
This is what I have using multiple choice. -- hp
$mcnullEQ = new_multiple_choice();
$mcnullEQ->qa(
"", "\( \le \)"
);
$mcnullEQ->extra(
"\( \ge \)",
"\( \ne \)","\( \gt \)","\( \lt \)" ,"\( = \)"
);
Hi Darwyn,
Could the error be as simple as being that the less than sign is interpreted as HTML markup? If so, I wonder if the following would work:
\{ pop_up_list(["?","=",$GT,$LT]) \} 1
Gavin
I suspect you are right on the right track Gavin, but I am not sure what you mean by $LT and $GT. Based on your suggestion I tried using the html code for lt:
\{ pop_up_list([$equal->string,'<',$greater->string]) \} 1
That puts a < symbol in the pop up list, but still marks it incorrect. As when I use "<", it prints a blank in the answer preview and marks it incorrect.
\{ pop_up_list([$equal->string,'<',$greater->string]) \} 1
That puts a < symbol in the pop up list, but still marks it incorrect. As when I use "<", it prints a blank in the answer preview and marks it incorrect.
Hi all,
This bug report
http://bugs.webwork.maa.org/show_bug.cgi?id=2756
suggests that removing HTML::Scrubber may fix the problem. Has this bug been resolved?
Here's a fix (really a hack) that will work: replace the less than symbol by the literal string "less than".
Best regards,
Paul Pearson
Hi Darwyn,
The variables $GT and $LT are predefined in the PG system to produce the appropriate markup according to the display mode. That is, in TeX/hardcopy mode they'll return > and <, and in HTML modes will return > and &lt;. It's possible that the embedding here won't make that work properly. The HTML::Scrubber problem that Paul mentioned could also be the issue, and would create similar results: it was cleaning out things that look like spurious HTML markup, which something like < looks like.
Gavin
We have problems with a popup as you describe, and we are using webwork 2.8 and pg 2.8. There does seem to be an odd workaround in the code, but it's been a while since we coded them, and I don't remember why. But probably it was a similar issue.
For the popup, $GTS and $LTS are used. For displaying the answer in the correct answer box, a Math Object string is used. Here are the bits from a problem of ours that matter:
To create a popup object and the answer:
Context()->strings->add('<'=>{},'>'=>{},'='=>{});
if($frac1 < $frac2)
{ $answer = String('<');
$popup = PopUp(["?", $LTS, $GTS, "="], $LTS); }
elsif($frac1 > $frac2)
{ $answer = String('>');
$popup = PopUp(["?", $LTS, $GTS, "="], $GTS); }
else
{ $answer = String('=');
$popup = PopUp(["?", $LTS, $GTS, "="], "="); }
To display it in a PGML block:
BEGIN_PGML
Choose [`[$LTS]`], [`[$GTS]`], or [`=`] to make a true statement.
[``-\frac{[$pos_a]}{[$b]}``] [@$popup->menu()@]* [``-\frac{[$pos_c]}{[$d]}``]
END_PGML
To assess it:
ANS( $popup->cmp(correct_ans_latex_string => $answer) );
Alex:
Your code is more complicated than is necessary. For instance, you don't need to add the strings to the context yourself, as PopUp() will do that for you. Also, you can just use "<" and ">" rather than $LTS and $GTS as PopUp() will handle those properly. (It doesn't seem to hurt it to use these here, but because macros like this already are escaped for the proper output mode, using them in PopUp() might cause double-escaping to occur, so I'd recommend not doing so in general.) You don't need to set the corrections_latex_string, as PopUp should handle that for you as well.
Finally, the initial creation of $popup can also be shortened. For example:
loadMacros("parserPopUp.pl","PGML.pl");
$f1 = 2; $f2 = 2;
@choices = ("<","=",">");
$popup = PopUp(["?",@choices],$choices[($f1 <=> $f2)+1]);
BEGIN_PGML
[`[$f1]`] [@$popup->menu()@]* [`[$f2]`]
END_PGML
ANS($popup->cmp);
Here I've used the "spaceship" operator <=>, which returns -1 if the first is less than the second, 0 if they are equal, and 1 if the first is greater than the second. Adding 1 to this makes it 0, 1, or 2, which can be used as an index into the @choices array.
If that is too fancy, you could use
if ($f1 < $f2) {$answer = "<"} elsif ($f1 == $f2) {$answer = "="} else {$answer = ">"}
$popup = PopUp(["?","<",">","="],$answer);
but that is up to you.
I think that the code became this awkward because it was the only way we could get the answer to show up correctly in the answer display box. It sounds like that HTML scrubber issue was at fault though. I'll try simplifying things, thanks!
The issue you are facing is due to incorrect application of HTML::Scrubber, as Paul suggested. That has been corrected in version 2.8 of PG and WeBWorK, so your original code is correct (if you have a current enough version). Rather than change the code, I'd upgrade WeBWorK.