calculator
calculator copied to clipboard
microsoft
Automatic scientific notation can't be disabled
Describe the bug In scientific mode scientific notation can be enabled by F-E button but can't be disabled if number have more than 2 zeros after decimal point. This automatic scientific notation is also enabled even on standard mode. Sometimes it's more useful and more readable if number stay in common decimal format instead of scientific notation. For example while calculating crypto currencies it is more useful to see 0.000005142857 where I can easily see 514 satoshi price than 5.142857e-6.
Steps To Reproduce
- Switch to standard or scientific mode
- Type 0.000036
- Press divide symbol
- Type 7
- Press Enter
- Pressing F-E is not changing output format
Expected behavior
- In Standard Mode, we should disable scientific notation. That is, if you input 0.000036/7, you should see 0.000005142857 as the result.
- In Scientific Mode, we should preserve the "auto-scientfic" behavior, though the F-E switch should be toggled on when we do so. You should be able to untoggle the F-E button to force a decimal result. If a user manually disables F-E, we should preserve that until the user clears all input or switches modes.
Other behaviors considered:
- Stay in normal decimal format until I press F-E to switch to scientific notation OR
- Show scientific notation but also enable F-E switch to indicate scientific notation mode with ability to disable F-E to show number in common decimal format OR
- Add another switch to enable/disable automatic scientific notation if number conains more than defined number of zeros after decimal point OR
- Disable automatic scientific notation in standard mode calculator at all and add another switch to enable/disable automatic scientific notation in scientific mode if numbers contains more than defined number of zeros after decimal point OR
- Add settings for automatic result rounding or display precision to any number of digits to prevent automatic scientific notation to trigger just because result contain lot of digits after decimal point which are not important for user
Device and Application Information (please complete the following information):
- OS Build: 10.0.17763.0
- Architecture: X64
- Application Version: 10.1812.10048.0
Note: A team member edited this comment for clarity on expected behavior
Another real life example:
Bitcoin price is 3478.90 €/BTC. How many BTC I'll get for 1€?
- Switch to standard or scientific mode
- Type 1
- Press divide symbol
- Type 3478.9
- Press Enter
Result is 2.8744718158e-4 which is hardly readable for me. I expect to see 0.00028744718158 to better understand visually how many decimals are there.
0.000036/7 = 5,1428571428571428571428571428571e-6 This has too many decimals for the 'F-E' button to work correctly.
If you copy the result, paste it in notepad, and remove some decimals to have 25 decimals like: 5,1428571428571428571428571e-6 When you copy/paste this to calculator, the 'F-E' button works.
Then settings for automatic result rounding should be solution. For example acountants don't need 32 digits precision for prices and other financial calculations. For them it is really annoying to see more than 2 or 4 digits. Same for cryptocurrencies where anything under 1 sathoshi is not imporant for Bitcoin. I'll add that solution to expected behavior.
This is your friendly Microsoft Issue Bot. I've seen this issue come in and have gone to tell a human about it.
@grochocki -- Can triage weigh in on this app behavior change (especially given that there is currently a PR linked to this untriaged Issue). Thanks.
I think the desired behavior here is a combination of a couple of your suggestions.
- ~~In Standard Mode, we should disable scientific notation. That is, if you input 0.000036/7, you should see 0.000005142857 as the result.~~
- In Scientific Mode, we should preserve the "auto-scientfic" behavior, though the F-E switch should be toggled on when we do so. You should be able to untoggle the F-E button to force a decimal result. If a user manually disables F-E, we should preserve that until the user clears all input or switches modes.
@uhliksk I am going to update your original issue for clarity on expected behavior.
It's not clear now what should happen in Standard mode for values that used to only be displayable with scientific notation. For example, in Standard mode, if I input 100,000,000 * 100,000,000, I get 1.e+16, which is correct. I can continue to perform operations on this value. After the change that is proposed, the result is simply Overflow.
Overall, this change would make it so that there is a large class of numbers we can compute in Standard mode, but we will bail out and tell the user we can't compute because we don't want to display scientific notation. It feels regressive compared to the current behavior.
It's not clear now what should happen in Standard mode for values that used to only be displayable with scientific notation. For example, in Standard mode, if I input 100,000,000 * 100,000,000, I get 1.e+16, which is correct.
Scientific mode is better suited for dealing with very large and very small number, but I agree that showing overflow in this case is not ideal. In #162, I proposed supporting 32 digits across both Standard and Scientific modes (instead of just 16 in Standard as we do today). While this would not fully address your concern (eventually, you will hit large enough numbers to still cause overflow), it does greatly extend the range of values we support before getting into that state. Perhaps that change can/should coincide with this fix.
engineering notation can be helpful in such cases. ie.
0.000036/7
results in
5.142,857 • 10-6
which is easier to comprehend and still compact.
Compact is not necessarily the goal as we do not want to lose precision. Today we display 5.142857142857143e-6, which is 5.142,857 • 10-6, but with greater precision.
I'm having the same issue here. As a user, I find it frustrating that the calculator won't show me simple decimal numbers even in Standard mode. I can certainly read scientific notation but it takes more thought.
It's baffling why 1/10000 shows 0.00001 whereas 1/2950 shows 3.389830508474576e-4. I was trying to estimate the period of a signal in microseconds, so 0.0003898... would have been much more intuitive at a glance.
I was trying to estimate the period of a signal in microseconds, so 0.0003898... would have been much more intuitive at a glance.
I think that the engineering presentation of 389.8 μs would have been even more intuitive.
I was trying to estimate the period of a signal in microseconds, so 0.0003898... would have been much more intuitive at a glance.
I think that the engineering presentation of
389.8 μswould have been even more intuitive.
Then it'll be more intuitive to show 389.8e-6 instead of 3.898e-4. I can create another Issue and PR to add option for exponents to be divisible by 3 (or another customizable value).
I am also interested in a fix. If the user wants standard, give standard, if user wants scientific, give scientific. I want standard so I can copy and paste to another file that doesn't accept scientific.
#1304 should provide us the UI affordance to toggle auto scientific notation off. I suggest we address this issue as part of implementation of #1304.
PLEASE PLEASE fix this. As a user, if I wanted a precise scientific notation, I would have switched to a precise scientific notation calculator... as a simpleton, why do I need to do more math after entering the math that I wanted done by my calculator???? How do I enter a times e-6 to get the 5.142857 to display to the display limit of the calculator.. 10 digits? 8 digits? If the reading is 0.0000000001, it's fine with me. If I wanted a more precise measurement of relatively nothing, I'd have switched to the scientific mode. I switched to the currency mode expecting 2 digits but the calc switched number layout to 10 key minus any functions... I'm not in tablet mode and touch screens are for toddlers and maybe or maybe not I actually have a number pad on my keyboard... But no.. I got a e-6 number and a horrible calculator on my pc.
How about asking the user how many decibels to display?
I would also love a solution to this issue. It is so annoying having to figure out how many zero's I need to have before the mess of numbers that fill my screen. Scientific notation is useful but not all the time, in fact for me it's very rare that I do use it. The calculator on Windows should allow us to toggle between in modes otherwise it renders this calculator useless honestly. I won't be using it till this issue is fixed!!!
If you all are waiting for Microsoft to fix this, you might as well go buy an Abacus. It is just a calculator after all, and Microsoft is not exactly known for it's ingenuity nor user-responsiveness. Just go download one of the 100's of replacements available on the web. Plenty of developers have already made far superior calculators than anything Microsoft is capable of (at least unless/until they buy one out, which would probably be faster than fixing their own code).
Just go download one of the 100's of replacements available on the web. Plenty of developers have already made far superior calculators than anything Microsoft is capable of (at least unless/until they buy one out, which would probably be faster than fixing their own code).
Why not both?
Microsoft are fing w*ers who never fix ANYTHING.
Bug creators? Yes muchly.
Bug fixers? NO
How many f***ing years old is this issue? What have they done about it? What's the purpose of even having this page here? Just to wind us up???
c##ts.
Microsoft. The biggest, most valuable, most cash-rich software company in the history of the world.
Do not have it within their capacity or their capability to fix a simple problem (decimal points) in the most simple program (calculator).
The F-E button does nothing. Why are you so concerned about precision anyway? And why would you lose precision by doing this? You can still preserve the same number of significant figures, the overall number would just be longer, although there could be issues with very large exponent. This is just a matter for the part that is converting the number to a string, there should be no precision loss in it?
The F-E button does nothing. Why are you so concerned about precision anyway? And why would you lose precision by doing this? You can still preserve the same number of significant figures, the overall number would just be longer, although there could be issues with very large exponent. This is just a matter for the part that is converting the number to a string, there should be no precision loss in it?
(1) Asking someone who is using a calculator to compute a value "Why are you so concerned about precision anyway?" is a pretty non-sensical question. If they didn't care about precision, they would just guestimate it rather than using a calculator.
In my case, one of the things I deal with is counting Photons on the nano-second time scale, as well as all of the timing values that go with that, so precision is pretty important to me. Maybe you are using it to ball-park a value, but most people would prefer the exact, correct, and complete answer.
(2) The F-E button changes how the values are displayed. Depending on many digits (and zeros to the left) the value currently being displayed has, it can either :
- Toggle between SN and 'normal' display
- (if already in SN) rounds the SN to X decimal places (X is not a fixed number in my experience. Today I've seen 20 and 28)
As for the loss in precision, I grant you that MS is listing the SN value to include 20, 30, (more?) digits, but that is NOT how SN is supposed to work, and it STILL rounds values with "too many" decimals. As far as I understand it, SN syntax generally only has a few decimal places included, and is best used to represent values with Zeros to the right OR many digits to the left of the decimal, like 0.000125 (1.25E+4) or 123456789 (1.235E-8). Using it on a value with Integer digits (or not) plus lots of decimals (with or without zeros to the right) is an exercise in stupidity because the SN version is actually longer, and if anything is harder to read, not easier ("How many places do I need to shift that decimal to get my real value?"). Try toggling the F-E button on the value for Pi to see what I mean.
I think the original point of this thread was that SN is not suited to all circumstances or use-cases, and it would be nice if it was not forced upon us, especially when there is NO GOOD REASON for it. But like I've said in previous posts (that mysteriously get 'hidden' as "off topic"), If you are waiting for MS to fix this, you are in for a very long wait. But I don't dare point you at another calculator program that works correctly, because it might upset someone at MS. (They don't like it when other people point out how to fix (or side-step) their failures. They would much rather you just suck it up like a good little user and let them fix it when and if they get around to it).
To Microsoft: If you need some help, just send me your code and I will fix it for you, pro-bono. You can even say you fixed it.
P.S.: I can't help myself : Go get SpeedCrunch. It'll give you 50 decimal places and control over the format.
I'd just like to copy/paste values from a calculator. Come on microsoft, sort your sh*tty calculator out.
... and stop wasting ^ all these ppl's time commenting on your crappy product
??? So there is someone here moderating the comments, but no fkkr doing anything about fixing the calculator??? Microsoft ALL OVER