Windows Calculator invalid input with 10^x function

[whoopdedo]

In comparison, Windows 7:

    powten(43429) -> Overflow
    powten(43430) -> Invalid input
    powten(4.3429) -> 22024.192788839535553954884105294
    powten(4.3430) -> 22029.264630534561834283309977748
    powten(4.3431) -> 22034.337640198758473587650545525

In Windows 10, 4.3431 results in "Invalid input" but 4.3429 does not. (Nor does 4.3430, but obviously so.)

What's the significance of 43430?

[userbinator]

Very interesting. The XP calc.exe/Calculator Plus is able to compute 10^43429 (and the result is 1.e+43429), but not 10^43430.

What's the significance of 43430?

    e^99999 = 1.0325137485899245994533393888277e+43429
    e^100000 = 2.8066633604261231793183858185717e+43429
    e^100001 = Invalid input for function.

(XP calc.exe)

According to Mathematica,

     e^100001 = 7.6293020112481304176946586569717e+43429
     e^100002 = 2.0738593021001839250781552880629e+43430

and likewise,

     ln(1e+43429) = 99998.968003638410011217350885487
     ln(1e+43430) = 100001.27058873140405690136887694

It's off by a tiny bit, but it's round enough to give some hints: 10^x is internally being computed using e^x.

Edit: some more interesting, possibly relevant search results for the numbers 43429 and 43430:

https://stackoverflow.com/questions/33515746/why-is-this-c-p...

http://delphiforfun.org/NewsLetters/Nbr32.htm

[JdeBP]

See https://news.ycombinator.com/item?id=17675777 on this page.

[MrEldritch]

https://imgur.com/a/ukSUOhM

Holy crap. How on Earth did they manage to break Windows Calculator, of all things?

[stan_rogers]

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.

[1] https://winaero.com/download.php?view.1795

[amenghra]

I have found (and reported) at least two similar bugs in Mac OS X's calculator. It's not just a Microsoft thing :)

In both instances, Apple didn't respond to the bug report until many years later, when they just closed it.

[zamadatix]

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.

[akerro]

In a few years Windows will be just a red button that makes farting sound when pressed.

EDIT: and telemetry.

[gnopgnip]

Until last month doing sqrt of 4 or other perfect squares would give small errors

[archvile]

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

[mehrdadn]

Wait, what? It works fine for me. https://imgur.com/a/LvZtIOd

[cup-of-tea]

Who cares? It looks all flat and fashionable which is what you really care about.

[gabriel34]

Seems the issue occurs at some range (10^0,39794 - ?]

  10^0,43407 - Invalid Input
  10^0,00001 - OK
  10^0,50001 - Invalid Input
  10^0,40001 - Invalid Input
  10^0,30001 - OK
  10^0,35001 - OK
  10^0,39999 - Invalid Input
  10^0,37501 - OK
  10^0,38751 - OK
  10^0,39375 - OK
  10^0,39794 - OK
  10^0,39795 - Invalid Input

But when I tried better approximations things got weird

  10^0,397941 - Invalid Input
  10^0,397940000001 - Invalid Input

Seems six or more decimal places result in Invalid Input

  10^0,39375 - OK
  10^0,393751 - Invalid Input
  10^0,39376 - OK

Even well outside the range

  10^0,123456 - Invalid Input

[psyklic]

There seems to be a clear pattern for > 5 digits after the decimal:

  5 digits - Valid: <=0.39794, Invalid: >=0.39795
    10^0.39794 < 2.5
    10^0.39795 > 2.5

  6 digits - Valid: <=0.043429, Invalid: >=0.043431
  7 digits - Valid: <=0.0043429, Invalid: >=0.0043431
  8 digits - Valid: <=0.00043429, Invalid: >=0.00043431

The pattern seems to continue as the number of decimal places increases.

[craftyguy]

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.'

[urda]

I love how the first comment is from a "guru" with nothing better to say than:

> Do you really think it is going to make much difference to the final answer?

Doesn't matter, it should work.

[tzs]

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).

Here's an article on how RPN evolved at HP: http://h20331.www2.hp.com/hpsub/downloads/S07%20HP%20RPN%20E...

[mikehollinger]

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.

I see the same thing in travel forums frequently.

[warent]

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...

[lukeify]

Power users on many forums love to adopt this attitude.

[excalibur]

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.

[romwell]

Someone in the comment thread suggested that perhaps the decimal point is ignored altogether, and some inputs get rejected as being too large.

If that is true, then 0.00001 is being tread the same as 1, but 12345 and 0.12345 are both considered being "too large".

FWIW, I can't reproduce the bug with my current Windows build (1703 / 15063.296).

[psyklic]

It seems that 0.00001 gives "Invalid Input", but 0.00000001 works.

EDIT: Strangely, now all inputs seem to work, even 0.00001 and even when I restart the calculator. Not sure why ...

[mistaken]

It's baffling to me why they don't implement arbitrary precision arithmetic. bc (a calcuator for unix) can do that since 1975 :)

[css]

This is from June and looks like it is fixed, I can do 10^x functions on my work PC in the Windows calculator.

Edit: see comment below

[MrEldritch]

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.

[excalibur]

Not fixed for me, fully patched 1803.

[zamadatix]

Some work, did you try greater than 5 digits like the post said?

[laacz]

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 ;)

[alkonaut]

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".

[nuclx]

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.

[askvictor]

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)

[ddtaylor]

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)

[Ice_cream_suit]

bc works well for me. See http://phodd.net/gnu-bc/

[jsilence]

Also emacs calc is a beast!