nus-pe-bot
commented
2 years ago Team's Response
This isn't integer overflow, it is float imprecision (goal is a float in the back-end) when the float gets too long. It is due to the limitations of the degree of precision floating point numbers can be represented in in the system – if the float is big/long enough the numbers start behaving weirdly. In any case using such a big number is likely to be a rare, although not impossible, occurrence.
The 'Original' Bug
[The team marked this bug as a duplicate of the following bug]
Goal input records large numbers incorrectly
When inputting large numbers for the /goal field for add, the actual number stored is different from the original intended number.
To replicate: input command as seen in picture.
[original: nus-cs2103-AY2122S1/pe-interim#1229] [original labels: type.FunctionalityBug severity.Medium]
Their Response to the 'Original' Bug
[This is the team's response to the above 'original' bug]
This is due to the limitations of the degree of precision floating point numbers can be represented in in the system (goal is represented as a float in the back end) – the larger/longer the value the more likely the float becomes represented inaccurately. In any case using such a big number (like in the billions as shown in the screenshot) is likely to be a rare, although not impossible, occurrence.
Items for the Tester to Verify
:question: Issue duplicate status
Team chose to mark this issue as a duplicate of another issue (as explained in the Team's response above)
- [ ] I disagree
Reason for disagreement: [replace this with your explanation]
:question: Issue type
Team chose [type.FunctionalityBug]
Originally [type.DocumentationBug]
- [ ] I disagree
Reason for disagreement: [replace this with your explanation]
:question: Issue severity
Team chose [severity.Low]
Originally [severity.VeryLow]
- [ ] I disagree
Reason for disagreement: [replace this with your explanation]
When testing the dashboard
addfeature, theGOALmust be a number greater than 0. However, it does not mention the upper limit of the number. I believe that this is a rare case and not needed, and I think it should be mentioned in the documentation. The command I tested is as follows: