You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
Open MS calculator.
Expand the hamburger menu by clicking on the button with the three horisontal stripes in the top left corner.
Click on "Scientific"
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.
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.
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
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.
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.
The text was updated successfully, but these errors were encountered:
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:
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:
Expected result: The expression should appear as 0-(0-3⁰)+3, and the correct answer, 4, is given.
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.
Screenshots
Device and Application Information
Run the following commands in Powershell and copy/paste the output.
PS C:\Users\jurie> " - OS Build: $([Environment]::OSVersion.Version)"
PS C:\Users\jurie> " - Architecture: $((Get-AppxPackage -Name Microsoft.WindowsCalculator).Architecture)"
PS C:\Users\jurie> " - Application Version: $((Get-AppxPackage -Name Microsoft.WindowsCalculator).Version)"
PS C:\Users\jurie> " - Region: $((Get-Culture).Name)"
PS C:\Users\jurie> " - Dev Version Installed: $($null -ne (Get-AppxPackage -Name Microsoft.WindowsCalculator.Dev))"
Additional context
Requested Assignment
I'm just reporting this problem. I don't want to fix it and wouldn't know how.
The text was updated successfully, but these errors were encountered: