Progress output does not take into account CS/CU modules

[nus-pe-bot]

I'm not sure why, but adding on an extra CS/CU module does not modify the recommended CAP for future modules, even though this should have increased due to the lower number of MCs left

Steps to replication:

1. Create a profile with average cap of approximately 3.2, and a progress goal of 4.5. Run progress to see the recommended future CAP.
2. add m/GEQ1000 (in either the same semester or a future semester) which decreases the number of SUs left, and hence would theoretically increase the average CAP required in the future. Run progress again and note that the recommended average future CAP has not changed from 1.

---

_{[original: nus-cs2103-AY2021S1/pe-interim#3846]}

[xyzhangg]

Team's Response

Hi, we have recreated the above scenario and comfirmed that the reason that the recommended average future CAP does not change is due to rounding, and it is consistent with the expected result.

The example we used is as follows: current CAP is 3.17 (approximately 3.2) and goal is set to 4.50

The formula we used to calculate the average future CAP is shown below:

[(Target cap Total graded MC) – (Current Cap Current graded MC)] / (Total MC required – current MC taken)

Using the above example and assuming the student takes 160 MCs (a lower total MC would result in a bigger change to the required future CAP if a future mod is CS/CU), the required future CAP is calculated as follows:

[4.50 160 - (3.17 12)] / (160 - 12) = 4.6078 (4 d.p.) = 4.61 (rounded to 2 d.p.)

Indeed, the progress command shows that the required average future CAP is 4.61:

Now, we add GEQ1000 as a CS/CU mod, and the required future MC is calculated as follows (total graded MC is reduced by 4 from 160 and current MC taken is increased by 4 from 12):

[4.50 (160 - 4) - (3.17 12)] / (160 - (12 + 4)) = 4.6108 (4 d.p.) = 4.61 (rounded to 2 d.p.)

When we run the progress command:

Now, the displayed required future CAP is still shown as 4.61, even though the actual required CAP is slightly higher compared to before. Due to design considerations, we decided to show the CAP as 2 d.p. for higher readability for the user. Thus, this behavior is not a bug as it is intended and consistent with the actual expected output.

Furthermore, we believe that the severity of this 'bug' should be low because the lack of precision in the recommended future CAP will very rarely, if not never, affect their goal for the actual grades of their future modules. A tiny difference in the recommended CAP will most likely not allow the user to change the required grade for a future module (i.e. from an A to A-), and the detailed calculations are shown below.

Considering the most extreme cases, when a user has 200 MCs left to take (the higher the MCs left, the lower the change in the required future CAP when one of the module's grade is changed):

Case 1: required future CAP = 4.50, user has to achieve on average an A- for all future modules.

Case 2: required future CAP = 4.51, user has to achieve on average an A- for all future modules, except for one 4 MC module which the user has to achieve an A ((4.50 196 + 5.00 4) / 200 = 4.51).

Comparing case 1 and 2, a difference of 0.01 (or higher) in required future CAP can indeed cause a difference in the goal for their actual grades for the future modules. However, since our lack of precision for the displayed required CAP is due to rounding, the error between the displayed and actual required CAP will not be more than 0.005. Furthermore, users are most likely to use the progress command when they have taken some modules already and thus left with lesser MCs, which will increase the 'diffrence in required future CAP' (> 0.01) needed to cause a difference in the goal for their actual grades.

Duplicate status (if any):

--