WeBWorK Problems

Why does order of factors matter for answer

by Tim Alderson -
Number of replies: 3

The following question marks a student answer as incorrect in part (d) unless the factorial factors are typed first.  For example, the answer for seed 1282 is 25*26!*4!, which is marked as incorrect unless entered as   26!*4!*25.

I cannot figure out why. Any suggestions welcome.

#######################################
## DBsubject(Discrete Mathematics)
## DBchapter(Permutations and Combinations)
## DBsection(Permutations)
## Level()
## KEYWORDS(permutations)
## TitleText1(Discrete Mathematics With Graph Theory)
## EditionText1(3)
## AuthorText1(Goodaire and Parmenter)
## Section1(7.1)
## Problem1(7)
## Author(Tim Alderson)
## Institution(University of New Brunswick Saint John)
## Language(en-CA)

DOCUMENT();

####################
####################
"PGstandard.pl",
"MathObjects.pl",
"PGML.pl",
"PCCmacros.pl",
"contextIntegerFunctions.pl",
"PGcourse.pl",
);

####################
####################
TEXT(beginproblem());

####################
# PG Setup
####################
Context("IntegerFunctions");
Context()->flags->set(tolerance => 0.1, tolType => "absolute");
$b = random(8,26); #define number of possible elements in set S do {$g = random(2,8);} until ($g !=$b);
$n = Compute($b+$g); #$nm1 = $n-1; #$np1 = $n+1; #P($bp1,n)
$bm1 =$b-1; #
$bp1 =$b+1; #
$gm1 =$g-1; #
$gp1 =$g+1; #
$ans1 = Compute("[$n]!");
$ans2 = Compute(" [$b]!*[$g]!*2!");$ans3 = Compute("[$g]!*[$bp1]!");
$ans4 = Compute("([$g]!)*([$b]!)*([$bm1])") ;

####################
# Body
####################
BEGIN_PGML
In how many ways can [$b] boys and [$g] girls sit in a row:

a.  with no restrictions?

[_____]{$ans1} a. If the boys sit together and the girls sit together.? [_____]{$ans2}

a.  If the girls sit together.?

[_____]{$ans3} a. If just the girls sit together.? [_____]{$ans4}

END_PGML

####################
# Solution
####################
BEGIN_PGML_SOLUTION
a.  This question asks for the number of ways to arrange [$n] people in a row. The answer is [$n]!.

a.  Step 1: Arrange the boys in a line: [$b]! ways Step 2: Arrange the girls in a line: [$g]! ways
Step 3: Put either the boys or the girls at the start of the line: 2  ways.

The answer is 2([$b]!)([$g]!).

a.  Step 1: Arrange the girls in one of [$g]! ways. Step 2: The girls form one block and the boys ten other blocks. These [$bp1] blocks can be arranged in one of [$bp1]! ways. The answer is [$g]![$bp1]!. a. Let [A] be the set of ways in which the girls sit together and [B] the set of ways in which the boys and girls each sit together. The question asks for [|A\setminus B|]: [|A\setminus B|=|A| - |A\cap B|] [|A|=[$g]![$bp1]!] (from part (c)), and [|A\cap B|=2([$b]!)([$g]!)] (from part (b)). Therefore the answer is [$g]![$bp1]!-2([$b]!)([$g]!)= [$bm1]([$g]![$b]!).

END_PGML_SOLUTION

####################
# End Problem
####################
ENDDOCUMENT();

Re: Why does order of factors matter for answer

by Danny Glin -

The short answer is that the numbers are too large.

I can't say that I fully understand the ins and outs of how perl stores numbers, but once the numbers get big you start getting overflow errors.

Some quick calculations show that once you get to 23! you start to lose precision.

Try the following:

$a = Real("23!");$b = sprintf("%f",$a->value); BEGIN_PGML [$b]

END_PGML

This will show you the numerical value of the MathObject \$a.  In my case (and this may be dependent on your version of perl and computer architecture) I get 25852016738884978212864.000000, which is off by about a million and a half.  I can't tell you specifically what is happening with the order of multiplication in your example, but the safest thing to do is stick to values below 2^63-1 when using integer arithmetic (which means nothing bigger than 20!).

Re: Why does order of factors matter for answer

by Alex Jordan -

Adding on to Danny's answer, I think that another piece of the puzzle is here:

Context()->flags->set(tolerance => 0.1, tolType => "absolute");

Absolute tolerance that is this small on numbers that are that large is not going to work. The loss of precision that Danny points out is applying in a different order for the two permutations, and in the end one version is within ±0.1 of the (similarly mangled) official correct answer, and one version is not.