By writing a whole new one without considering the 20%. It's also missing a lot of features compared to the old one. (Features that may not matter to everyone, granted, but I found that there were more things that weren't there for my typical uses than ones that were.) Installing the old calculator[1] isn't much of a problem, though - although you do need to pin it to make it easily accessible without finding yourself opening the new uselessness accidentally about 50% of the time.
They wrote a new calculator for Win10, but AFAIK this breakage wasn't because they actually rewrote it again (as evidenced by the fact that it hasn't changed in any other obvious ways), but because of some subtle and as-yet-unknown change --- exactly the type of thing that horrifies me about silent automatic updates. What used to work is now subtly broken, and no one knows why.
Googling around, I found another discussion on it:
If you're going to add something, add something better than the old Calc, unless you really need some feature that only exists on that Calc. I use their PowerCalc Powertoy for Windows XP. [1] There's also SpeedCrunch which in some ways is probably better (minus the plotting) but personally I'm used to PowerCalc.
(No, not the new abomination of the same name that comes up when you search for "Calculator Plus", but the original XP-era one that is now only available from archive.org. Irritatingly enough, MS removed the old --- and better --- one when they introduced the new one.)
It's easier to get than finding an XP installation or ISO to extract a calc.exe from. The installer is also signed by MS, which may be a factor in some highly locked-down corporate environments.
It wouldn't surprise me - I'll often do the same with Python on non-Windows systems rather than bothering with the native calculator; I'm not even sure if Linux has one (or if it's the same across distros), and Python is ubiquitous, fast, and has familiar syntax.
Personally I used to use Maple for this kind of thing circa 2002. It used to launch on Windows in a fraction of a second (faster than the built in calculator tool!), and was an amazing calculator for pretty much any purpose.
Unfortunately some version of Maple around that time switched to a Java-based front end, and thereafter took forever to load, and had a UI littered with glitches.
I've used J (a language in the APL lineage) as an interactive calculator before. It makes some things pretty easy, especially if you need to operate on series of numbers.
What's the sum of the numbers from 15 to 20 inclusive?
i.6 N.B. Returns an array 0 1 2 3 4 5
15 + i.6 N.B. Returns an array 15 16 17 18 19 20
+/ 15 + i.6 N.B. returns the number 105
edit: Or course, if we're talking about languages helpful for calculation, we simply must include a reference to https://frinklang.org/
They're learning from GNOME! (GNOME whatever the latest version includes a new calculator that is an awful step backwards compared to the old one, luckily I can still install the old one).
And it is slower, really noticeably slower in terms of startup time than the old calc.exe in windows 7 and before. Not to mention it covers 50% of the screen for no reason.
If the new one just wraps the old one, but the new one breaks on certain inputs, how is it breaking? Maybe the outer "new" layer uses a new string to number parser than the inner "old" layer used to use, and that's where the bugs are being introduced?
They continued to update the underlying engine with new features and bug fixes and new bugs, they just didn't rewrite it from scratch.
Apparently a recent update also fixed a longstanding problem where the square root of a perfect square integer doesn't give you the exact right answer, so maybe there was a general change to the implementation of exponents and roots which may have introduced this bug too.
If I had to take a first guess since 1e10000 is an overflow in the current version therefore x = 1e9999 is the last valid 10^x input. If that holds true my guess would be someone added a check for that input but did it as "5 or more digits" rather than "10,000 or more".
My second guess is they are using some weird algorithm that hits an error case due to the limits of whatever number type they are using.
I wonder if they're using a fraction type to store decimals (a reasonable way to avoid floating-point error), and when the 10^x function is implemented naively on this type, 10^(3.1415) becomes 10^(31415/10000) = (10^31415 / 10^10000) = (overflow / overflow).
What’s even more bizarre is how often they update the Win10 calculator app from the Windows store. Never had any idea that a calculator would need bi-weekly updates, but shrug
Just checked, calc fails at 11^0.41703 (curiously not at 41703, but 41704, maybe a floating point thing). Maybe it changes base to e and uses the Taylor series for e^x, but fails if x is too precise for what it expects?
if only the source code were publicly available, then the real problem could be realized, patches proposed, etc. enjoy waiting on microsoft to patch it, they're probably too busy 'loving open source.'
Even from a strictly business standpoint it certainly makes sense to open-source things like the calculator, since I doubt the source contains any proprietary IP that gives it any particular competitive advantage --- and in the "basic calculator app" space, there is certainly a lot of competition.
Then again, the fact that they managed to break one of the most conceptually simple applications that comes with Windows --- for seemingly no good reason at all --- speaks volumes about the quality of MS products these days...
I'm not sure what you're trying to say. Are we supposed to consider it normal that something which used to work is now broken? I hope not, especially with something as well-defined as a calculator.
> Then again, the fact that they managed to break one of the most conceptually simple applications that comes with Windows --- for seemingly no good reason at all --- speaks volumes about the quality of MS products these days...
You think that's bad? I once reported a bug in Apple's calculator in OS X, and it was fixed by the next release.
If you started out with a cleared calculator with default settings and computed 14479.14 - 152.36 you got 14326.78.
If you started out with a cleared calculator with default settings and computed 1143/78, and then computed 14479.14 - 152.36, you got something like 14326.779999999999.
The number of people on forums who completely missed the point and lectured me, often rather condescendingly, on how neither 14479.14 nor 152.36 are exactly representable in finite binary floating point and so that is why the subtraction was not exact was astonishing.
The bug is not that the subtraction is inexact. The bug is that the same subtraction result was displayed with different rounding depending on whether it was done immediately after a clear or done after computing 1143/78.
How 14479.14 - 152.36 displays should only depend on the calculator settings. That it changed depending on previous calculations suggest that there was probably a scratch variable used during calculations that was supposed to be reset before the next calculation but was not.
Speaking of the MacOS calculator, their RPN mode really annoys me (although not as much as Windows 10 calculator which doesn't even have an RPN mode!). Suppose you want to compute (2+3) x 4. The obvious key sequence works: 2 enter 3 + 4 x.
How about (2+3) x pi. The obvious key sequence is: 2 enter 3 + pi x. The result of that is an error beep with pi in the display, or, if you had anything on the stack before you started, that thing multiplied by pi.
That's because rather than pushing pi onto the stack, the pi key replaces whatever is on the bottom of the stack with pi. In other words, instead of acting as if you had hit the keys 3 . 1 4 1 5 9 ... 7 9 3, it acts as if it pops the stack, invokes the function
def pi(x):
return 3.141592653589793
on the value it popped, and pushes the result.
What you have to do is: 2 enter 3 + enter pi x.
Suppose you decide you don't want to have to remember the distinction between the pi key and numerical entry, and decide to just always put in that enter.
So: 2 enter 3 + enter 4 x. That gives you 20 like you would expect...but also leaves a 5 on the stack above that.
For comparison, that does not happen on an HP-15, or on software calculators that follow HP RPN rules, such as pcalc on iOS. On those, when you press enter it duplicates the item currently on the top of the stack, just like Apple's calculator, but it sets a flag that says if you immediately enter a number, that overwrites the top of stack instead of pushing.
This flag was a key thing that made data entry on the HP calculators feel natural.
On the HP-48 they made a significant change to this. When you pressed enter it did not immediately dup the stack and set the flag saying numerical entry should overwrite. Instead, pressing enter did not immediately do anything to the stack. Instead, it set a flag saying that if your next action was to enter a number, first dup the top of stack.
The RPN mode on pcalc lets you select if you want HP-48 stack behavior or classic RPN behavior (it is in advanced settings when you are in RPN mode).
How 14479.14 - 152.36 displays should only depend on the calculator settings. That it changed depending on previous calculations suggest that there was probably a scratch variable used during calculations that was supposed to be reset before the next calculation but was not.
...and my guess is that "scratch variable" is actually a flag that switches calculations between fixed-point and floating-point mode; the first subtraction was done in fixed-point mode, but when it did the division it used floating-point, and then kept that mode for future calculations until explicitly cleared.
This!!! I've noticed how "forums" (as opposed to reddit-style discussion boards which are moderated) tend to have this sort of "first post!11!!!" behavior. If you look at that user's post history, he or she has contributed, but - also is providing lots, and lots of commentary. And while that commentary is useful, it's not necessarily moving the ball on solving whatever the problem of the day is.
Some guy answering every post with some generic "try these troubleshooting steps" which are all completely unrelated to the question. That guy should be a bot or a sticky post...
I'm wondering if there are sites that have people on agreements to answer "200 posts/month" for a fixed pay or something, or get paid per answered question within 48h. In any case: it's not helping.
I get you're being a bit coy, but I have no trouble believing it's just some person who enjoys the small power rush of being "the guy w/ the answers". I've seen this tons of times with employees in Slack/Teams chat, ones who just chime in on virtually any topic with a copy/paste answer and a condescending attitude. It's a power thing, they enjoy being the one who knows everything and lays down the law.
From both a technical and managerial standpoint, it can be insanely frustrating, with the only bright-side being that for very basic questions you at least get good coverage.
I think about community quality content a lot. I see a lot of abuse of this all over reddit and other forums and stack overflow too. People have figured out how to game the system. I think the internet is ready for some forum software that uses machine learning to decide whether content is high or low quality. It could analyze the replies, the context, the content, the user's history, posting rates, all sorts of data is available to recognize low quality content and low quality users. Especially when you realize that a lot of reddit accounts are bots that farm points and then get sold. ML seems like the only real way to protect communities against this!
> People have figured out how to game the system. I think the internet is ready for some forum software that uses machine learning to decide whether content is high or low quality.
Great idea. Then there'll be absolutely no chance people will find a way to game the system.
This really stood out to me as well. That kind of response is, for lack of a better word, cringy. "You probably don't need that anyway so ignore the fact that it's broken!" Sure...
The differentiation is neither "digits" nor "significant figures". 10000 throws the "invalid input" error, while 0.00000001 does not. Both of these numbers have exactly one significant figure, and the latter clearly has more digits.
Confirmed, on mine .43407 gives "Invalid input". I was getting "Invalid input" earlier for 0.00001 and 0.00003 (the first two examples I tried), but now they seem to work.
EDIT: Manually typing in 10, the x^y button, then 0.43407 also gives "Invalid input".
Not fixed for me - I just tried 10^0.43407 and yup, "Invalid Input". And I know I'm up to date because I just came back to find my PC in the middle of updating the other day.
For me one of my updates had failed, so I was still getting security patches but not major version upgrades. Had to figure out the problem (media feature pack) and then update.
This made me check and apparently IT here (large international networking hardware company) hasn't patched Windows since April. I always assumed everything auto updated, evidently our policy is the exact opposite.
What is your full version number? If you open the command prompt it should say something like Microsoft Windows [Version 10.0.17134.???]. You could also run 'ver'.
You should probably be looking at the calculator version (menu button -> About. mine is 10.1806.1821.0, and has this problem) rather than the OS version. Apps can be updated independently of the OS.
Whoa, very interesting, great call! I see 10.1712.10601.0 as the version for mine. Why would it not have updated along with the rest of Windows? EDIT: Oh, because I've disabled automatic app updates. :-)
I see this as perfect opportunity for Microsoft to show how they're all open and transparent.
1. Introduce a bug which only 1% would encounter.
2. Wait for it to get noticed.
3. Fix the bug, explain the causes in detail, thank everyone.
4. Profit ;)
Can confirm I have this and I'm on the fastest insider build ring. There seems to be differences between how input is made etc which leads me to think there is something more to it than just "makes the wrong calculation".
I wouldn't trust the windows calculator anyways for anything beyond trivial arithmetic. Use an environment where you have actual control over how the calculations are performed.
This doesn't appear to be only with the 10^x function - the x^y function exhibits the same behaviour (both for x=10 and at the least x=9; I haven't tried many others)
I guess when you are Microsoft you don't have to test software internally since millions will do it for you for free. Also for what it's worth I didn't have any problems with these numbers on `kcalc` in KDE (not that I expected to see it, but worth a shot)
What's the significance of 43430?