
Windows Calculator invalid input with 10^x function - userbinator
https://www.tenforums.com/software-apps/111414-windows-calculator-invalid-input-10-x-function.html
======
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...](https://stackoverflow.com/questions/33515746/why-is-this-c-program-
crashes-on-windows-and-works-fine-on-linux)

[http://delphiforfun.org/NewsLetters/Nbr32.htm](http://delphiforfun.org/NewsLetters/Nbr32.htm)

~~~
psyklic
Nice work! The internal use of e^x also was confirmed below for the Windows 10
calc (using another method).

------
MrEldritch
[https://imgur.com/a/ukSUOhM](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](https://winaero.com/download.php?view.1795)

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

[1] [https://imgur.com/gi0jmdI](https://imgur.com/gi0jmdI)

~~~
pavelbr
I launch apl in my terminal if the calculation I need to do is simple and
Wolfram|Alpha otherwise

~~~
mehrdadn
APL as in... the programming language? Or something else? I'm not sure what
you're referring to.

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

~~~
deadbunny
Same here, I don't have an actual calculator program so python is generally
the quickest way for me.

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

~~~
barbegal
10^0.043429 ~= e^0.1

10^0.0043429 ~= e^0.01

10^0.00043429 ~= e^0.001

So that gives some insight into the algorithm that is being used

~~~
gabriel34
Using this we can actually predict the smallest exponent that fails for other
bases:

    
    
      base	exponent (6 digits)
      10	0.043429
      11	0.041703
      12	0.040243
      2	0.144271
      3	0.091024
      4	0.072135
      1000	0.014476
    

(the calculated exponent for two is actually 0.144270, but since it ends in
zero the first failure occurs at 0.144271)

~~~
imran3740
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?

------
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...](http://h20331.www2.hp.com/hpsub/downloads/S07%20HP%20RPN%20Evolves%20V5b.pdf)

~~~
userbinator
_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.

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

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

~~~
MrEldritch
Just tried again - .00001 works for me, but .43407 still doesn't...

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

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

~~~
excalibur
Not fixed for me, fully patched 1803.

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

~~~
excalibur
Yeah, I guess I can tell you that. I'm on 10.0.17134.191

~~~
mehrdadn
Yeah same as mine, that should be fully patched indeed. Except I can't
reproduce the problem on mine, so this is really bizarre:
[https://news.ycombinator.com/item?id=17675413](https://news.ycombinator.com/item?id=17675413)

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

~~~
mehrdadn
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. :-)

------
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/](http://phodd.net/gnu-bc/)

~~~
jsilence
Also emacs calc is a beast!

