T&Q: Calculated question rounding error for answer key
Description
Attachments
- 20 Aug 2024, 06:49 AM
- 20 Aug 2024, 06:28 AM
- 22 Jul 2024, 11:24 PM
Activity

Wasi Khan August 20, 2024 at 6:49 AM
Ignore last comment (tested wrong server), QA verification passed on the right server:
Sakai 22-SNAPSHOT
This panel contains information about the server that can be used for troubleshooting. The panel can include server time, your preferred time, the server name, and the build information.
Server Time:
Tue, 20 Aug 2024 02:48:59 EDT
Server:
ip-172-31-7-189
Build Info:
492dd24f

Wasi Khan August 20, 2024 at 6:28 AM
Failed on 22, the answer key displayed 2.646 as follows:

Wasi Khan August 19, 2024 at 4:16 AM
Verified on 23, saw 2.645 on answer key.
Server Information
Sakai Version: 23-SNAPSHOT
Server Time: Aug 19, 2024 12:15:13 AM EDT
Server: ip-172-31-7-189
Build Info: 53180359
Christina Schwiebert August 8, 2024 at 6:58 PM
Verified on Trunk - https://trunk-maria.nightly.sakaiproject.org/, build f247bf83. The given test question is rounded to 2.645

Automation for Jira July 23, 2024 at 12:03 AM
A pull request has been created, "SAK-50321 T&Q: Calculated question rounding error for answer key", you can see it at https://github.com/sakaiproject/sakai/pull/12750
Details
Details
Priority
Affects versions
Fix versions
23 Status
22 Status
21 Status
Components
Assignee

Reporter

The Answer key can display an incorrect value due to a rounding error for an edge case like the following.
For example, suppose a very precise and correct answer for a formula is “2.6454798891706”. Now suppose the formula is configured to display 3 decimal places for the correct answer. The answer key currently presents the correct answer with a rounding error.
Currently: The answer key displays as 2.646.
Expected: The answer key should display as 2.645.
This rounding error happens because SamigoExpressionParser.parse returns the string “2.6455” as the answer, which is rounded again downstream (by some client code) to 2.646. These kinds of rounding errors could be prevented by modifying the parse method to return a string with an extra decimal place of precision (e.g., “2.6548” would be rounded to the expected “2.645”).
For what it’s worth, I encountered this problem by testing the following trigonometry example from the T&Q help document, How do I create a calculated question?
Solve: COS({a}) * ({c} - {b}) = {{z}}
A student’s case arose where variable values resulted in:
COS(4.087) * (3.652 - 8.171)
Using a scientific calculator --with angles set to radians (instead of degrees)-- I discovered that a precise answer like 2.6454798891706 would be presented in the answer key as 2.646 instead of 2.645 (with the default setting of 3 decimal places).