The Windows Calculator no longer generates tiny errors when calculating the square root of a perfect square

Some time ago, I explained why the Windows Calculator generates tiny errors when calculating the square root of a perfect square.

Good news! Square roots of perfect squares are now exact!

In fact, it's more than just square roots of perfect squares. Perfect cube roots of perfect cubes are also exact. In general, rational roots and powers of integers will come out exact if the result is an integer. For example, raising 8 to the ⅔ power will produce 4 exactly.

Getting the exact result is considerably more computationally expensive, but the calculator is not a performance-sensitive program. If calculating the ⅔ power of a number takes an extra 10 milliseconds, nobody will care.

When the Calculator team announced this change at an internal event, they wore custom-made T-shirts that said



Comments (34)
  1. Gee Law says:

    That Calculator did not compute perfect roots without floating-point errors stirred quite a debate on a Chinese question website (something like Quora)

    I wonder why this improvement is made. Presumably, there are more prioritized issues than this one, and it should have been preempted.

    1. The improvement was made precisely because the fact that Calculator did not compute perfect roots without floating-point errors stirred quite a debate (and make the Calculator team look bad: “Look how bad Calculator is, It can’t even do basic elementary school math right!”).

      1. Joshua says:

        Too bad I can’t use it. Explorer shell (and therefore all modern apps because they won’t start w/o explorer shell) drains more power than 2x Visual Studios.

        1. DWalker07 says:

          Do you have any evidence to back up that claim?

      2. matrix says:

        Calculator Team? May I ask how many members this team has? Looks like a perfect job, are you hiring?

  2. Kirby FC says:

    One other curiosity I noticed, when doing something like
    square root of 16
    minus 4
    the calculator in Windows 10 (prior to this fix) returned a wrong answer that was different from the wrong answer produced by the calculator in Windows 7.

    1. Darran Rowe says:

      Actually, -4 is a correct answer to square root of 16. Since 4² and (-4)² result in 16, then the true “correct” answer to sqrt(16) is ±4.
      The reason why we normally just take the positive root for most things is that in the natural world we don’t see things like negative lengths or whatever.

      1. Gee Law says:

        sqrt means the principal square root.

      2. Brian_EE says:

        Ok – but shouldn’t the answer be 0 (or in your example, -8)? sqrt(4) – 4 equals either +4-4 or -4-4.

        1. Brian_EE says:

          On my Win7 calc: sqrt(4) minus 4 = -4.601736559325006786000070237498e-38
          while the sequence: sqrt(4), ± key, minus 4 = -8

    2. I think the responders are misparsing Kirby’s comment.

      My parsing of it is that evaluating the expression “sqrt(16) − 4” produced a different wrong answer on different versions of Calculator. Presumably, both wrongs answers are small numbers that are close (but not equal) to 0. I don’t think he’s trying to say that any versions of Calculator would return −4 as the answer to sqrt(16). That would be mathematically correct, but it isn’t something that any modern calculator software ever returns, AFAIAW.

  3. Andre says:

    Would be interesting to read how this works behind the scenes.
    Arbitrary precision for rationals is not too hard, but I have no idea how to generalize this to algebraic numbers.

    1. N S says:

      Most likely the reason for the error is that it’s using natural logarithms to calculate square roots. -> sqrt(4) = e^( ln(4) / 2).
      If I perform this and subtract the square root of 4 calculated using the square root button I get zero.

  4. Kirby FC says:

    Can someone please share the secret html voodoo that is required to insert link breaks here? So far, nothing I have tried works.


    1. Joshua says:

      Two consecutive linebreaks turn into paragraph breaks.

      1. Kirby FC says:

        Not for me. When I do that, it is ignored. The b tag is also ignored.

  5. JAS says:

    Why not expose Calculator’s math library? The code will probably not change again for another 20 years. I like that these roots are being calculated correctly but I hate the Windows 10 calculator with a passion and .NET still doesn’t have a BigDecimal counterpart.

    1. Brian_EE says:

      I agree that the Win10 calculator was a big step backwards for technical people.

      I also dislike the fact that switching views on the Win7 calculator zeroes out the value. Maybe I want to compute the cosine of a number, multiply by 128, and then switch to programmer view to convert to binary…. nope. have to remember the result and type it back in after I switch views. My 30 year old desk calculator on the other hand – no problem.

      1. pmbAustin says:

        I’m curious about why you say this. I love the Win10 Calculator, and wish it were on Android since it’s better than any calculator I’ve found there. Why do you think Win10 calc was a step backwards compared to the much more limited Win7 version?

        1. Kevin says:

          Because for unary operations, the calculator requires you to push buttons in RPN order (e.g. to take sin^2 of 5 you enter 5, sin, x^2), for binary operations it uses infix order (to get 4 – 2 you enter 4, minus, 2), and it displays intermediate values right below the expression for which they are the wrong answer (e.g. if you enter 5, sin, x^2, plus, 5, cos, x^2, it shows the full sum-of-the-squares expression, but the number displayed immediately below this expression is some franken-number; to get the expected value of 1, you have to hit the = key, which is not at all obvious the first time you use it). I’m fine with a four-function calculator acting like a four-function calculator, but I would much rather my scientific calculator either go full RPN or go full Texas Instruments prefix/infix.

  6. Martin Bonner says:

    I think you will find <br> will do it:
    Should be a new line

    This is just a new paragraph.

    1. Kirby FC says:

      I’ve tried , it is ignored.

      I’ve tried multiple blank lines, it is ignored.

      1. In most cases, you do want a new paragraph, not a new line within a paragraph. In most cases when people simply use a line break, they should actually be using a new paragraph. In Swedish, there is even a word for this typographical error: “radstycke”.

  7. Kirby FC says:

    typo: Should be Line Breaks, not link breaks. Sorry.

  8. alexandrooo says:

    time for new t-shirts with easy math “1+1*2=4”

    1. Brian says:

      Well, that’s interesting/weird. If I do that in my head (using my grade school precedence rules), I get 3, not 4. If I do that in either of the Scientific or Programmer views on the Win10 calculator, I get 3 as well. But, if I do that in the plain-old Standard view, I get 4.

  9. Neil says:

    For square roots there’s always the method of long division which neatly works very well in binary, but obviously that doesn’t readily generalise to arbitrary rational roots.

  10. What do the numbers on the shirt mean?

    1. Aged .Net Guy says:

      It’s one number word-wrapped to fit on a T-shirt, not three separate numbers. So the value is -1.blahblahblah142 E-19 which is very, very, VERY close to zero but is not equal to zero.

      As to why that particular number, see Raymond’s earlier blog entry that he referenced in the first sentence of this blog entry.

      At the meta level, the T-shirt is commemorating chasing and defeating this very numerically tiny but conceptually huge defect.

    2. zboot says:

      That was the previous result of sqrt(4) – 2 on the calculator (instead of 0).

    3. zboot says:

      This is a real email address and I’m not a first time commenter. . .

    4. Brian says:

      Follow the link up at the top of the posting to “Why does the Windows calculator generate tiny errors when calculating the square root of a perfect square” and see

  11. R P (MSFT) says:

    For their next trick, can they make sqr(sin(45)) == sin(30)?

Comments are closed.

Skip to main content