From facd737ee47a5f58505b602c4be6bf637ff25426 Mon Sep 17 00:00:00 2001 From: Feanil Patel Date: Thu, 24 Oct 2019 15:00:35 -0400 Subject: [PATCH] Update code to use the new rounding method in course_grades. So making this code change took a few hours. But then deciding that it was the right one of the many options available took the next 3 days. When changing to the new rounding function, we had a test that started failing. It appears as if our new rounding function is not the same in some way as the one built into python 2. ``` >>> round(.0045*100 + .05)/100 0.0 >>> round_away_from_zero(.0045*100 + .05)/100 0.01 ``` Doing the math by hand we see that the new function is actually correct but the old one is clearly rounding incorrectly in this case. Looking closer at this I discovered that it was due to a floating point issue where .0045*100 is represented as 0.44999999999999996 so when we add 0.05 to this number we get 0.49999999999999994. This is all because of the limitations of floating point arithmetic. See https://docs.python.org/3/tutorial/floatingpoint.html#tut-fp-issues for more on that. Because python does its rounding at the bit level in C code. It treats the .4999... as below the .5 cutoff and rounds down. Whereas our code does more simple arithmetic which causes the number to correct itself before we round and so correctly rounds up to 0.01 The result of this change is that previously, the rounding threshold used to be that any number > .0045 would ronud to 0.01 and now any number that is >= .0045 rounds to 0.01 Note that if we only care about the two most significant digits of number between 0 and 1, this error only manifests itself in such a way that other than the case of going from 0.00 to 0.01 eg. from 0% to 1% none of the other cases where we would now round up cause the 2 most significant digits to change. Given this level of impact, we're fine with this change. In our tests we see this for one case, where an incomplete turns into an F in a test. I'm updating the test here to be more correct. As we were looking at it we speculated as to why we were adding the .05 to the number. Could it be to counteract this floating point issue? It turns out not. Looking at this commit(a1286b1c7db979c9ab4bd89c7feef2) we see that it looks like this was intended to always round up to the nearest percentage point. However, there's a typo here. If you wanted to ensure that we always rounded up to the nearest percentage point you would have the math be `round(final_grade_percent*100 + 0.5)/ 100` or a simpler way to do this would be `math.ceil(final_grade_percent*100)/100`. However, that is not what happened and 7 years later, there have been a lot of people graded with the wrong rounding where essentialy anyone with a grade of 89.45 gets a 90 when the intended impact was supposed to be that anyone with a grade above an 89.0 would get a grade of 90. Changing it now requires a lot of conversation and wolud have a large impact on existing learners. So we are not going to change it as a part of the python 2 -> python 3 upgrade. I have created https://openedx.atlassian.net/browse/TNL-6972 to capture this issue if we want to address it in the future. --- lms/djangoapps/grades/course_grade.py | 5 ++++- lms/djangoapps/instructor/tests/test_spoc_gradebook.py | 4 ++-- 2 files changed, 6 insertions(+), 3 deletions(-) diff --git a/lms/djangoapps/grades/course_grade.py b/lms/djangoapps/grades/course_grade.py index dcc5bf363b..fb8181d7da 100644 --- a/lms/djangoapps/grades/course_grade.py +++ b/lms/djangoapps/grades/course_grade.py @@ -12,6 +12,7 @@ from django.conf import settings from django.utils.encoding import python_2_unicode_compatible from lazy import lazy +from openedx.core.lib.grade_utils import round_away_from_zero from xmodule import block_metadata_utils from .config import assume_zero_if_absent @@ -296,7 +297,9 @@ class CourseGrade(CourseGradeBase): Computes and returns the grade percentage from the given result from the grader. """ - return round(grader_result['percent'] * 100 + 0.05) / 100 + + # Confused about the addition of .05 here? See https://openedx.atlassian.net/browse/TNL-6972 + return round_away_from_zero(grader_result['percent'] * 100 + 0.05) / 100 @staticmethod def _compute_letter_grade(grade_cutoffs, percent): diff --git a/lms/djangoapps/instructor/tests/test_spoc_gradebook.py b/lms/djangoapps/instructor/tests/test_spoc_gradebook.py index 078d753c66..1fa34bbf04 100644 --- a/lms/djangoapps/instructor/tests/test_spoc_gradebook.py +++ b/lms/djangoapps/instructor/tests/test_spoc_gradebook.py @@ -104,11 +104,11 @@ class TestDefaultGradingPolicy(TestGradebook): # Users 1-10 attempted any homework (and get Fs) [10] # Users 4-10 scored enough to not get rounded to 0 for the class (and get Fs) [7] # One use at top of the page [1] - self.assertEqual(22, self.response.content.count(b'grade_F')) + self.assertEqual(23, self.response.content.count(b'grade_F')) # All other grades are None [29 categories * 11 users - 27 non-empty grades = 292] # One use at the top of the page [1] - self.assertEqual(293, self.response.content.count(b'grade_None')) + self.assertEqual(292, self.response.content.count(b'grade_None')) class TestLetterCutoffPolicy(TestGradebook):