## WeBWorK Problems

### help with Fraction type ### help with Fraction type

by Giorgi Shonia -
Number of replies: 4
Appreciate if someone please could help why the following code is failing. Interestingly, if I put Compute instead of Real (bold red line) it works. I'm also attaching screenshot of error message, it shows the "same" submitted=correct answer, but incorrect status.

##DESCRIPTION
##  Algebra problem: true or false for inequality
##ENDDESCRIPTION

##KEYWORDS('algebra', 'inequality', 'fraction')

## DBsubject('Algebra')
## DBchapter('Fundamentals')
## DBsection('Real Numbers')
## Date('6/3/2002')
## Author('Giorgi Shonia')
## Institution('')
## TitleText1('Precalculus')
## EditionText1('3')
## AuthorText1('Stewart, Redlin, Watson')
## Section1('1.1')
## Problem1('22')

########################################################################

DOCUMENT();

"PGstandard.pl",     # Standard macros for PG language
"MathObjects.pl",
"contextFraction.pl",
"unionTables.pl"
#"contextLimitedPowers.pl"
#"source.pl",        # allows code to be displayed on certain sites.
#"PGcourse.pl",      # Customization file for the course
);

# 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()->flags->set( # tolerance => 0.01, # tolType => "absolute", #); do {$a=Real(random(6, 8, 0.01))} while ((10*($a-floor($a))==0));

$b=Real(100*(7.62-7)); #$b=62;
Context("Fraction");
$f=Fraction($b,100);

##############################################################
#
#  Text
#
#

Context()->texStrings;
BEGIN_TEXT

Please simplify, convert decimal into fraction and percentage. Please use at least 2 digits precision for percentage. Please enter fraction in two separate boxes as whole and (reduced) fraction part, eg 7 2/5. $BR $a$ $b$ \{$f->ans_rule(10)\} $BR$BR

END_TEXT
Context()->normalStrings;

##############################################################
#
#
#

ANS($f->cmp); # relative tolerance --3.1412 is incorrect but 3.1413 is correct # default tolerance is .01 or one percent. ENDDOCUMENT();  In reply to Giorgi Shonia ### Re: help with Fraction type by Davide Cervone - It turns out that there is a small issue with the Fraction MathObject class that doesn't usually show up, but does in your case. The issue is that 100*(7.62-7) is not actually equal to 62. In the conversion to binary, some things are repeating "decimals" (binimals?) that are not repeating in base 10 (for example, .1 is a repeating decimal in binary notation), and so they get truncated when stored on a computer. When you multiply by 100, you don't necessarily get back the integer you expect because of the loss of the tail of the decimal. In your case, it turns out that 62 - 100*(7.62-7) equals about 1.421E-14, a very small number, but non-zero none the less. So when your $b value is used in the fraction, result is not actually equal to 62/100.

The issue with the Fraction object is that it is not comparing the correct and student answers using the "fuzzy" tolerances, but is doing a direct perl real comparison. That is OK when the numerator and denominator are actual integers, but not when they are reals very close to an integer, as in your case.

One way to resolve this is to use

my ($a,$b) = reduce(int($x*$d),$d); return [$Real->make($a),$Real->make($b)]; } This has the not-so-nice effect of turning the real 1/3 into the Fraction 333333/1000000. Fractions created this way must have denominators built from 2s and 5s. Instead, if this subroutine used a continued fraction algorithm tweaked in the right way, then not only would 1/3 stay put as 1/3, but also 62 - 1.421E-14 would become 62/1. Numbers like pi would become 355/113 after only four iterations of the algorithm, rather than 3141593/1000000. I could give a continued fraction algorithm, but there are probably better ones out there in the internet. I think a key ingredient would be that, at the stage where you take the reciprocal, if that number is very small, like smaller than the zeroLevel, then the algorithm should terminate early. (It absolutely has to terminate if the number is 0). This would allow 62 - 1.421E-14 to become 62, and also 0.333333333333333 to become 1/3. And there would be other considerations: how many iterations are necessary to allow for denominators on the order of 1000000? how many iterations would be too many: so many that rounding error could creep in and actually affect the integers that are stored as part of the continued fraction process? I'm curious what Davide or any other developers think. In reply to Alex Jordan ### Re: help with Fraction type by Alex Jordan - Here is some code I have been using for this. The Fraction context needs to be in use. contFrac(x,n) returns a Fraction that is very close to x using continued fraction approximation. The function is recursive and n is a depth countdown. Using 30 for n will ensure that any rational value for x with six-digit (or less) denominator will be caught and output as a Fraction equal to x. (This also catches many rationals with larger denominators.) For irrationals and other rationals with bigger denominators, either the algorithm stops after n iterations or when the kth integer part is over 10^8. For example, contFrac(10+10**-9,n) will always output Fraction(10,1). But contFrac(10+10**-8,1) will output Fraction(999999911,99999991). sub contFrac { my$real = shift;
my $counter = shift; my$intpart = floor($real); my$partial;
if (($real -$intpart > 1/10**8) and ($counter>0)) {$partial = contFrac(1/($real -$intpart ), $counter-1);} else {return Fraction($intpart,1)};
return 1/$partial+$intpart ;
}; ### Re: help with Fraction type

by Giorgi Shonia -

related (full code below). I create Fractons $np and$bp, Reals $nq and$bq and then calculate $t1=Real(($np*$nq)+($bp*$bq)) which I convert back to LimitedProperFraction, which is to be entered an (fraction) answer. I realize this is a poor practice? With bringing Real in the middle of calculation I create some approximations, which when converted back to fraction will create nearby, but different (then calculated using algebra arithmetic) rational? I am attaching a screenshot of such error (seed 10). Should I have kept everything in Fraction and overloaded operations would use fraction arithmetic? ##DESCRIPTION ## Algebra problem: true or false for inequality ##ENDDESCRIPTION ##KEYWORDS('algebra', 'inequality', 'fraction') ## DBsubject('Algebra') ## DBchapter('Fundamentals') ## DBsection('Real Numbers') ## Date('6/3/2002') ## Author('') ## Institution('') ## TitleText1('Precalculus') ## EditionText1('3') ## AuthorText1('Stewart, Redlin, Watson') ## Section1('1.1') ## Problem1('22') ######################################################################## DOCUMENT(); loadMacros( "PGstandard.pl", # Standard macros for PG language "MathObjects.pl", "contextFraction.pl" #"source.pl", # allows code to be displayed on certain sites. #"PGcourse.pl", # Customization file for the course ); # 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()->flags->set(
#tolerance=>0.001,
#tolType=>"absolute");

foreach my $i ($np, $bp){$q=Real(random(3,9,1));
$p=Real(random(2*$q+1,5*$q,1)); while (gcd($p,$q)==$q){$p=Real(random(2*$q+1,5*$q,1));} Context("LimitedProperFraction");$i=Fraction($p,$q);
}

# this code it bad. Staring with reals, calculation and then fraction, creates #cumulative precision error

$nq=Real(random(20,40,1));$bq=Real(random(15,35,1));
$t1=Real(($np*$nq)+($bp*$bq)); Context("LimitedProperFraction"); #Context()->flags->set(showMixedNumbers=>0);$a=Fraction("$t1"); ############################################################## # # Text # # Context()->texStrings; BEGIN_TEXT Handcrafted jewelery$BR
One necklace can be completed in $$np$$ minutes, and a bracelet takes $$bp$$ minutes. Find the total time that it takes to complete $$nq$$ necklaces and $$bq$$ bracelets.

Please enter answer as a reduced fraction, possibly with a mixed part.

$BR$BR
\{$a->ans_rule\}$BR
END_TEXT
Context()->normalStrings;

##############################################################
# 