WeBWorK Main Forum

Setting zeroLevel to allow small numbers seems to have no effect.

Setting zeroLevel to allow small numbers seems to have no effect.

by Christian Seberino -
Number of replies: 6
I'm trying to have Webwork accept the value 8.85E-13
but it keeps interpreting it as a zero.  

I've tried lots of combos like the following but no success.

Context("Numeric");
Context()->flags->set(
      zeroLevel => 1E-20,
      tolType => "relative",
      tolerance => 0.01E-13
   );
In reply to Christian Seberino

Re: Setting zeroLevel to allow small numbers seems to have no effect.

by Arnold Pizer -
Hi Christian,

Using absolute tolerance  works:

ANS(Real(8.85E-13)->cmp(
  tolType => 'absolute',
  tolerance => 8.85E-15,
));

so e.g. entering 0 will give an incorrect result. Entering 8.85E-13 or 08.85E-13 +08.85E-16 will give correct results. 

HOWEVER when you enter 8.85E-13, answer preview displays 0 (08.85E-13 +08.85E-16 previews as 0+0) which is obviously confusing. Not sure how to fix that. I tried using "Compute" but that didn't work, at least the way I tried.

Arnie

In reply to Arnold Pizer

Re: Setting zeroLevel to allow small numbers seems to have no effect.

by Christian Seberino -
Arnie

Thanks!  OK So I'm not crazy.  I'm glad it grades correctly.  

Not previewing correctly is a big problem because I will forever
have students asking the teacher why Webwork is not working
correctly when they preview.

cs
In reply to Christian Seberino

Re: Setting zeroLevel to allow small numbers seems to have no effect.

by Davide Cervone -
Try setting zeroLevelTol => 1E-20 as well. This is the value that tells MathObjects what counts as zero, and since the default is 1E-12, your value is below that, so is considered zero. That is why it displays as zero. But the answer checking is comparing your 8.85E-13 to the student's answer, and since neither is within the zeroLevel, they are compared as relative error. Note, however, that your tolerance means that the student answer has to be correct to about 15 significant digits (so correct o the 28th place or so. I don't think you really want to use such a small tolerance. Remember that this is relative error, not absolute error, so if you really only care about three significant digits, you want tolernace=>0.01 or so. (so the student has to be correct to 1E-15).

Davide
In reply to Davide Cervone

Re: Setting zeroLevel to allow small numbers seems to have no effect.

by Arnold Pizer -
Hi Davide,

In my example I set " tolType => 'absolute' " so, at least for checking student answers, it should not be using relative error.  Am I missing something? But as you say, using relative tolerance with a very small zeroLevelTol may be a better option.  

Is the preview hardwired to use zeroLevelTol, etc even though the answer checker is using absolute tolerance?  One could be using a custom answer checker, so it is not clear what the previewer should do. Probably using zeroLevelTol is the best option.  If it uses zeroLevelTol, then for a problem such as Christian is interested, if he chooses to use absolute tolerance, he could still set a very small zeroLevelTol so that 8.85E-13 would not be previewed as zero.

Arnie 
In reply to Arnold Pizer

Re: Setting zeroLevel to allow small numbers seems to have no effect.

by Davide Cervone -
Arnie:

You are correct about the tolerance (but I was responding to the original post, not yours, so wanted to point out the problem with the relative error). In any case, the tolerance value doesn't affect the preview display problem.

For the display, MathObjects asks the question "Is the correct answer zero?" (in order to avoid printing things like 3.276E-16 for an answer that should be zero). This means that the correct answer is being compared to zero, and in a comparison, when one of the two values is within the zeroLevel of zero (which in this case it is, since one IS zero), absolute error is used with the zeroLevelTol. So, yes, zeroLevelTol is what controls the display, and that is hard coded.

On the other hand, when the student answer is checked against the correct one, neither of which is zero, the zeroLevelTol is only used when one is within zeroLevel of zero. In the case described by the OP, since zeroLevel is smaller than the student and correct answers, the zeroLevelTol doesn't come into play, and the answer is graded correctly (but displayed as zero).

I suspect it is best to set both when you set one of them, so that they remain relatively synchronized. The defaults are not equal, and I'm not sure exactly why zeroLevelTol is larger than zeroLevel, but that is how it was historically, so that is what is done in MathObjects. The fact that zeroLevelTol is larger than zeroLevel does mean that you can get this strange behavior (displayed as zero, but checked as non-zero).

Davide
In reply to Davide Cervone

Re: Setting zeroLevel to allow small numbers seems to have no effect.

by Christian Seberino -
That did it!!  

The following previews correctly and grades correctly if you need
to allow numbers around 1E-13 like I did...

Context("Numeric") ; Context()->flags->set(tolerance => 0.03);
Context()->flags->set(
        zeroLevel => 1E-20,
        zeroLevelTol => 1E-20
);