Adding large total expense causes hard to read format of total expense

[Arif-Khalid]

I suggest making the format more readable, especially for people who are unaware of the mathematical notation of E.
In addition, this is an uncommon way of showing a dollar amount that users will not be used to.

[nus-pe-script]

Team's Response

Hi we are aware of the format of total expense, and we tried to resolve it, but due to the limitation of the language, it just display large numbers as such. Initially, we did not restrict the size of the amount that users can enter, this results in rounding off of numbers when adding, and also the issue you pointed out. One way we can resolve it is to limit the size of expense that can be entered, which we already did (limit of 9999999999.99). This solves the rounding off issue, but the number is still displayed as power of 10 format. We were thinking if we want to lower the limit of income / expense that can be entered, but we felt that the tradeoff will be higher, as we are restricting the expenditure of large ticketed items which can cost a lot. Logically, if users are able to spend that much of money (999999999.99), they should be smart enough to know the mathematical notion of E.

The 'Original' Bug

[The team marked this bug as a duplicate of the following bug]

Total Expense format

The total expenses at the last line seems to be hard for user to interpret and understand, as it displays in power of 10 format.

---

_{[original: nus-cs2113-AY2223S2/pe-interim#1520] [original labels: severity.VeryLow type.FeatureFlaw]}

Their Response to the 'Original' Bug

[This is the team's response to the above 'original' bug]

Thanks for pointing it out. We are also aware of this issue, and tried to solve it. But the language just converts the large number on its own, and sometimes round the numbers off if too large a number is entered. Hence we limited the size of the numbers entered to prevent the rounding off problem. But the complier still prints out the numbers in power of 10 format, which we cannot prevent.

Items for the Tester to Verify

❓ 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]

---

❓ Issue response

Team chose [response.NotInScope]

• I disagree

Reason for disagreement: [replace this with your explanation]

---

❓ Issue severity

Team chose [severity.VeryLow]
Originally [severity.Low]

• I disagree

Reason for disagreement: I think it should be severity.Low over very low because it is not a purely cosmetic issue. As a user it would cause minor inconvenience for me to interpret the format stated. Thus it should be severity.low over very low

---