Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inconsistent implementation in Calculator #2299

Open
JurieUK opened this issue Feb 18, 2025 · 0 comments
Open

Inconsistent implementation in Calculator #2299

JurieUK opened this issue Feb 18, 2025 · 0 comments

Comments

@JurieUK
Copy link

JurieUK commented Feb 18, 2025

Describe the bug

Regarding the mathematical expression -(-3⁰)+3, when entering it as 0-(0-3⁰)+3, the result correctly gives 4, which follows standard order of operations and matches conventional mathematical rules. However, when entering the expression as 0-(-3⁰)+3, the result incorrectly returns 2.

While I am not a coding expert, it has been suggested that this could be symptomatic of one or more issues:

  • A bug in parsing complex nested negatives
  • An inconsistent handling of negation and parentheses
  • Inconsistent interpretation of the unary negative sign
  • The application may be using different evaluation strategies when a leading zero is present

These discrepancies suggest there may be an issue in how the app processes certain types of expressions involving negation, parentheses, and leading zeros.

Steps To Reproduce

Steps to reproduce the behavior:

  1. Open MS calculator.
  2. Expand the hamburger menu by clicking on the button with the three horisontal stripes in the top left corner.
  3. Click on "Scientific"
  4. Enter the expression -(-3⁰)+3, but first click the "-" button, followed by the "3" button to enter -3.
    Expected result: The expression should appear as 0-(0-3⁰)+3, and the correct answer, 4, is given.
  5. Enter the same expression -(-3⁰)+3, but this time click the "3" button, followed by the "+/-" button to enter -3.
    Expected result: The expression should appear as 0-(-3⁰)+3, and the incorrect answer, 2, is given.

Expected behavior

Unless the original developers had some innovative new interface or ideas in mind, I would suggest that, when in scientific mode, the app should behave more like a standard, scientific calculator.

  1. The calculator should correctly follow the standard order of operations, including the precedence of exponents over unary negation. For example, for the expression -(-3⁰) + 3, the expected outcome is:
  • Evaluate the exponent first: 3⁰ = 1
  • Apply the inner negation: -3⁰ = -1
  • Apply the outer negation: −(-1) = 1
  • Add the result to 3: 1+3=4
  1. Consistent Handling of Leading Zeros and Negation:
  • Leading zeros should not appear in the output unless explicitly entered by the user. For example, if the user enters -3, the output should display -3, not 0-3.
  • The calculator should allow users to input negative expressions directly as -(expression) without automatically inserting a leading zero, i.e., it should support inputs like -(2+2) instead of forcing 0-(2+2).
  • The behavior of the +/- toggle should consistently switch the sign without introducing a negate() function or altering the order of operations.

Screenshots

Image

Image

Device and Application Information

  • OS Build: 22631.4890
  • Architecture: 64-bit operating system, x64-based processor
  • Application Version: 11.2411.1.0
  • Region: United Kingdom
  • Dev Version Installed: Stable Public Release

Run the following commands in Powershell and copy/paste the output.

PS C:\Users\jurie> " - OS Build: $([Environment]::OSVersion.Version)"

  • OS Build: 10.0.22631.0
    PS C:\Users\jurie> " - Architecture: $((Get-AppxPackage -Name Microsoft.WindowsCalculator).Architecture)"
  • Architecture: X64
    PS C:\Users\jurie> " - Application Version: $((Get-AppxPackage -Name Microsoft.WindowsCalculator).Version)"
  • Application Version: 11.2411.1.0
    PS C:\Users\jurie> " - Region: $((Get-Culture).Name)"
  • Region: en-US
    PS C:\Users\jurie> " - Dev Version Installed: $($null -ne (Get-AppxPackage -Name Microsoft.WindowsCalculator.Dev))"

Additional context

  • The current implementation automatically adds a leading zero when entering a negative sign before a bracketed expression (e.g., entering -( becomes 0-(). While this helps avoid syntax errors, it can lead to inconsistent interpretation of expressions and unexpected outputs.
  • There is no option to directly write a negative bracketed expression, like -(2+2). The calculator forces the user to write it as 0-(2+2) or converts it to negate(2+2) when using the +/- toggle, which also negates the result simultaneously.
  • This design feels somewhat clunky and inconsistent with standard scientific calculators. It would be more intuitive to allow direct input of negative expressions without altering the syntax or order of operations.
  • Clarification is needed on whether this behavior is intentional or a design oversight.

Requested Assignment

I'm just reporting this problem. I don't want to fix it and wouldn't know how.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant