Something wrong with fractions close to zero(?)

[billy...@gmail.com]

Hi all,

Various attempts at coding this question follow. The answer is comb(13,7)/comb(52,7) = 1716/133784560.

In the following screenshots, I've set the minimum and maximum answers to comb(13,n)/comb(52,n), and the display answer to rational(comb(13,n)/comb(52,n)). It doesn't accept the correct answer, and has mistakenly "simplified" it to a different fraction, which it also doesn't accept.

In the following, the minimum, maximum and display answers are all comb(13,n)/comb(52,n). The "display correct answer as fraction" box is ticked, but it gives me a decimal anyway. It doesn't accept the right answer, the wrong fraction or the wrong decimal.

In the following, I set all of the minimum, maximum and display answers to rational(comb(13,n)/comb(52,n)). It will finally accept the wrong answer! (But not the right one.)

I could try other permutations of options, but this makes me nervous about the way Numbas handles very small numbers! Am I doing something wrong, or are these known bugs?

Thanks, and best wishes,

Billy

[Christian Lawson-Perfect]

Those aren't terribly small numbers. There must be a bug somewhere. I'll look into it next week. 

--
You received this message because you are subscribed to the Google Groups "Numbas Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to numbas-users...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/numbas-users/152058d8-c916-4563-8d8f-7f560c403a68n%40googlegroups.com.

[Christian Lawson-Perfect]

OK, I've looked at this, and there is a way to make it work, but I'd like to set things up so that you don't have to know the technical details I'm about to tell you.

The `comb` function returns a value of type "number", with a floating-point value. That's only accurate to about 14 or so significant figures, in general. So if you use a "number" value as the minimum or maximum expected value for a number entry part, Numbas adds some "wiggle room" to the values, to account for the low precision, before converting them to a "decimal" value which can maintain much higher precision and accuracy.

I found a bug, which was that the wiggle room depends on the number of significant figures in the value, but the "convert to decimal" step was fixed to round the number to 15 decimal places. So in this case, wiggle room of 10^-17 was being added, and that was immediately lost. So both the minimum and maximum values were exactly the same value: the correct answer, rounded to 15 decimal places. The marking script checks that your answer is between the minimum and maximum. When you enter a fraction, it's represented precisely, so it wasn't considered to be within the correct range.

I've made a change which will make this question work: when converting a "number" value to "decimal", if the number's precision is greater than 15 decimal places, that precision is kept. So for this number entry part, the wiggle room is maintained and the correct value falls inside it.

However, ideally you wouldn't encounter a "number" value in this question at all: you're working with integers, and then ratios of them which should be represented as rational numbers. If the `comb` function returned an "integer" value instead of "number", you'd end up with a "rational" value for the part's expected answer. I've put a new issue in the tracker about this: https://github.com/numbas/Numbas/issues/1090. I don't want to make this change straight away until I've convinced myself that it won't break anything currently relying on the existing, slightly-wrong behaviour.

For now, you could fix your calculation by changing `comb(x,n)` to `round(comb(x,n))`, forcing it to be converted to an "integer" value.