Letter Grades, Weighted Categories -- course grade calculation boundary annomalies

Description

Weighted Categories - Letter Grades.
equally weighted items setting in category
items assigned equal points

equal number of two neighboring grades:
A+ A
A A-
A- B+
B+ B
B B-
B- C+
C+ C
C C-
C- D+
D+ D
D D-
D- F

course grades calculated for different points values:
15 20 100
A A+ A+
A A- A
A- A- A-
B B+ B+
B B- B
B- B- B-
C C+ C+
C C- C
C- C- C-
D D+ D+
D D- D
D- D- D-

see attached screenshots from spreadsheets.

Environment

win XP, Firefox 3.6.8 smartsite-dev.rsmart.com 2.6.4.0 - Sakai 2.6.2 - Server "ucddev1"

Attachments

5

Activity

Show:

David Woods August 7, 2010 at 5:23 PM

I can no longer find a combination that chooses a course grade in a non rational way (i.e. always choosing to either round up or round down in all cases where the calculated grade is exactly midway between to course letter grade values.)

Since I can't find a way to get an unexpected grade, this is a QA pass

Thomas Amsler August 6, 2010 at 7:26 PM

This is now on smartsite-dev.rsmart.com as part of the 1.3.0-b13 tag.

Thomas Amsler August 6, 2010 at 3:58 PM

Discussed fix during meeting where Kirk was present.

Kirk Alexander August 6, 2010 at 1:44 PM

I thought one of the previous fixes was steering AWAY from MATH_CONTEXT. Let's be sure we are consistent here. I would concur that this is a blocker. Can we get the fix on test26 for testing?

Thomas Amsler August 6, 2010 at 12:44 PM

So David and I did some more checking on this issue. It turns out that "today" all the gradebooks show the problem in a "consistent" manner. This is true for DEV, TEST, and PROD.

The issue is the following. Given the following grades, we get the following final grade:

HW1, HW2 --> Final Grade
A+, A --> A
A, A- --> A
A-, B+ --> A-

It should consistently round up to the higher grade, so we should get:
A+, A --> A+
A, A- --> A
A-, B+ --> A-

The problem is that we don't consistently use precision and or scale. For example the above (A+,A --> A) compares the following numbers:
96.666666668222222220877777777800000000000000
96.66666667

The fix is to "force" the percentage that's passed into the convertPercentageToLetterGrade(...) method to adhere to the general MATH_CONTEXT. I tested this locally and it seems to fix this issue.

Fixed

Details

Assignee

Reporter

QA Status

PASS

Components

Fix versions

Affects versions

Priority

Created August 5, 2010 at 4:51 PM
Updated August 10, 2010 at 9:30 AM
Resolved August 6, 2010 at 3:57 PM