search

EugeneTeu / pe

0 stars 0 forks source link

0 in front of cost is accepted as output e.g 0 #2

Open EugeneTeu opened 5 years ago

EugeneTeu commented 5 years ago

Expected Behavior

I expect to not be able to enter the wrong input cost e.g 00000001.80

Current Behavior

This is accepted by the system and it corrects it to 1.80 automatically, but no error message tells me that i have entered a wrong input for cost

Possible Solution

Steps to Reproduce

  1. Enter add n/chicken breast c/00000001.80 d/today t/meat Screenshot 2019-11-15 at 4.28.46 PM.png

  2. output:

Screenshot 2019-11-15 at 4.28.52 PM.png

Nowhere in the ug states that this is acceptable. Should either be an error message or the system must tell the user it changed their input cost.

nus-pe-bot commented 5 years ago

Team's Response

Hi, thank you for testing our application and issuing this bug report.

As per normal Mathematics, leading zeroes in front of a number will be ignored. 00000001.80 is essentially not a wrong input cost as the value of it is equivalent to 1.80. It has at most 2 decimal places and is greater than 0. Thus, it will be considered a valid cost.

Try keying 00000001.80 into a physical calculator, the output will be 1.8. This shows that this idea of ignoring leading zeroes is widely accepted and would not require an error message of any sort.

Hence, this bug report will be rejected as we do not see how this is a bug.

Items for the Tester to Verify

:question: Issue response

Team chose [response.Rejected]

Reason for disagreement: [replace this with your reason]