BUG in Windows Calc [modified]

[wibleywoo]

As expected same error occures with: 9 sqrt - 3 16 sqrt - 4 ...

[ErikKnowles]

Oh geez, this is *not* a bug. Do you have *any* idea of how floating point math is performed? Internal vs. reported precision? You're a programmer??? I'm gobsmacked that this got posted to a code developer site. Oh, and you made CodeProject's daily e-mail, so your ignorance has been transmitted worldwide. Epic fail.

modified on Tuesday, November 2, 2010 4:35 PM

[oconnellc]

Actually, it is accurate. Its problem is that it is *too* precise. If it was a little less precise, it would have decided that it was close enough to zero to just display zero.

[bwallan]

Interesting BUT the Scientific view doesn't have a "sqrt" key; however, the x^y gives the same BUG... bwa

[Plamen Dragiyski]

Woooow, I always use scientific calc in XP and I didn't know it is support sqrt... it seems that they forget to add that button into scientific dialog :laugh:

[Jake Barney]

In this particular instance any answer other than -4 or 0 is inaccurate. Doesn't matter that most of us understand that anything ^-39 power is so small as to be considered zero by most, it's still not zero. Understandably the answer they factored was 1.9999...8164whatever but its funny that the calculator rounded up, then 'forgot' that it did so. Sounds like sloppy programming. What's really funny is change it to the scientific calculator, do 4^.5 power then -2 and it gives a different answer.

[Sasa Cetkovic]

On Windows Server 2008 R2 it gives the first answer in scientific mode, and the second in standard mode.

[David C Thompson]

It works (well, the bug works) with any number. I tried sqrt(25) - 5 and sqrt(9) - :^)

[David C Thompson]

Can you enlighten those of us who may not be as well-informed as you?

[Caslen]

For all you Numptys who this this is a bug - you can easily prove that it isn't, follow these simple steps:- 1. Convert the number 4 to a binary floating point representation and write it down. 2. Continue with your pen and paper and using a suitably selected algorithm to calculate the square root of a number presented in binary floating point form work out the square root of the binary floating point representation of the number 4 found in step 1. 3. Convert the number 2 into a binary floating point form (preferably the same form as that used in step 1) 4. Perform a floating point binary subtract on the result of step 3 from the result of step 4. 5. Do you have zero? No you do not!

[Michael Kingsford Gray]

It needs to do it like HP calculators have always done.

[peterchen]

How did they?

Agh! Reality! My Archnemesis![^]
| FoldWithUs! | sighist | WhoIncludes - Analyzing C++ include file hierarchy

[NPowDev]

However, I thing it hould work in Calc, and fp-precision is not an excuse! I don't have the time to write a .NET application, but... Just a litle test in PowerShell:

PS > write-host ([Math]::Sqrt(4) - 2)
0
PS > write-host ([Math]::Sqrt(4.0) - 2.0)
0
PS > write-host ([Math]::Sqrt([double]4.0) - [double]2.0)
0
PS > write-host ([Math]::Sqrt([single]4.0) - [single]2.0)
0
PS > write-host ([Math]::Sqrt([decimal]4.0) - [decimal]2.0)
0

also to get sure that it is not a convertion issue:

PS > write-host ([Math]::Sqrt([decimal]4.0) - [decimal]2.0).toString("g")
0
PS > write-host ([Math]::Sqrt([decimal]4.0) - [decimal]2.0).toString("n")
0.00
PS > write-host ([Math]::Sqrt([decimal]4.0) - [decimal]2.0).toString("E")
0.000000E+000
PS > write-host ([Math]::Sqrt([decimal]4.0) - [decimal]2.0).toString("G17")
0
PS > write-host ([Math]::Sqrt([decimal]4.0) - [decimal]2.0).toString("G")
0
PS > write-host ([Math]::Sqrt([decimal]4.0) - [decimal]2.0).toString("n")
0.00
PS > write-host ([Math]::Sqrt([decimal]4.0) - [decimal]2.0).toString("n5")
0.00000
PS > write-host ([Math]::Sqrt([decimal]4.0) - [decimal]2.0).toString("n17")
0.00000000000000000
PS > write-host ([Math]::Sqrt([decimal]4.0) - [decimal]2.0).toString("n57")
0.000000000000000000000000000000000000000000000000000000000
PS > write-host ([Math]::Sqrt([decimal]4.0) - [decimal]2.0).toString("f57")
0.000000000000000000000000000000000000000000000000000000000
PS > write-host ([Math]::Sqrt([single]4.0) - [single]2.0).toString("f55")
0,0000000000000000000000000000000000000000000000000000000
PS > write-host ([Math]::Sqrt([single]4.0) - [single]2.0).toString("f155")
f155
PS > write-host ([Math]::Sqrt([single]4.0) - [single]2.0).toString("f95")
0.00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
PS > write-host ([Math]::Sqrt([single]4.0) - [single]2.0).toString("f99")
0.000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
PS > write-host ([Math]::Sqrt([single]4.0) - [single]2.0).toString("n99")
0.000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
PS > write-host ([Math]::Sqrt([single]4.0) - [single]2.0).toString("e99")
0.00000000000000000000000000000000000000000000000000000000000

Well... it's a M$ Numpyts! :-D

[Caslen]

Not quite sure what this proves but I hope you had fun doing it! :laugh:

[Juan Pablo G C]

Ja ja, in W2K8 the same -8,1648465955514287168521180122928e-39 :) I think someone forgot clear the stack

Juan Pablo G.C. Overrider Blog

[Trajan McGill]

I think you miss the point. A user calculator working in decimal shouldn't be wrong in decimal. And it certainly shouldn't be "right" and then become "wrong" again. If sqrt(4) is not actually calculated to be 2, then it shouldn't be shown as that. "2-2 != 0" is mathematically false, even when converted to binary representation. If the internal representation of "braking" in your electric car's computer worked by subtracting integer amounts from your velocity, and thus you could never (unless you were really, really lucky about when you hit the brake) actually come to a stop, but your car instead slowed way down and then vibrated intensely forward and backward as long as you held the brake pedal, you would not conclude "this is not a bug, it happens because of the way braking is represented internally". You would conclude that the internal representation was inappropriate for the task-- that we should make the car work with the human meaning of "braking", not conform ourselves to the sloppy approximation.

[Caslen]

I think maybe you missed the point:- 1. Did you not get the sarcasm? Oh hang on your American you wouldn't. 2. I don't really care whether it's logically right or wrong the fact is its wrong but because of a rounding error NOT a bug and that error is so small that here in the real world where I live it will never matter. But apart from that I did enjoy your little story even if it did have no bearing whatsover on the point in hand :)

[Trajan McGill]

I see. So you're saying: 1. This was sarcasm, but you took me seriously. Haha stupid American. 2. I was serious. Are you sure you have a proper definition of what "sarcasm" means? Because I'm pretty sure points 1 and 2 are mutually exclusive. Furthermore, "this is a rounding error, not a bug?" Well, at least now I know where all those amazing and beautiful "this is by design" bug responses come from. If a thing presents itself as a decimal calculator, and the responses it gives to decimal calculations are mathematically incorrect, then there is a bug. You can't say it isn't a bug just because the bug happens to be "we relied on an underlying implementation that doesn't work for the task". And by the way, in the real world, the difference between zero and nonzero is often very, very important to computer programs.

[Earl Truss]

Exactly ... The following works correctly in XP. click '4' click x^y click .5 click = click Int click '-'(Minus sign) click '2' Without using the Int function the result is the same as for the original poster.

[Michael Kingsford Gray]

Do everything in high precision normalised BCD instead of IEEE binary floating point types.