BUG in Windows Calc [modified]
-
Follow the procedure click '4' click 'sqrt' click '-'(Minus sign) click '2' Answer should be 0 But It comes back with '-8.1648465955514287168521180122928e-39' answer ;P [Edit] Tested with XP and Seven _[/More Edit] Windows Server 2008 R2 comes same with yet another answer '-1.068281969439142e-19' _[/More Edit] [/Edit]
Rating is Always appreciated.
Regards,
Hiren Solanki.
Indian Forum | My Articles | My Profile
"You will always find me near 127.0.0.1"
modified on Monday, November 1, 2010 7:00 AM
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
-
Sheesh, it's about right, whaddaya want, accuracy :-)
-
Follow the procedure click '4' click 'sqrt' click '-'(Minus sign) click '2' Answer should be 0 But It comes back with '-8.1648465955514287168521180122928e-39' answer ;P [Edit] Tested with XP and Seven _[/More Edit] Windows Server 2008 R2 comes same with yet another answer '-1.068281969439142e-19' _[/More Edit] [/Edit]
Rating is Always appreciated.
Regards,
Hiren Solanki.
Indian Forum | My Articles | My Profile
"You will always find me near 127.0.0.1"
modified on Monday, November 1, 2010 7:00 AM
-
Follow the procedure click '4' click 'sqrt' click '-'(Minus sign) click '2' Answer should be 0 But It comes back with '-8.1648465955514287168521180122928e-39' answer ;P [Edit] Tested with XP and Seven _[/More Edit] Windows Server 2008 R2 comes same with yet another answer '-1.068281969439142e-19' _[/More Edit] [/Edit]
Rating is Always appreciated.
Regards,
Hiren Solanki.
Indian Forum | My Articles | My Profile
"You will always find me near 127.0.0.1"
modified on Monday, November 1, 2010 7:00 AM
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:
-
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.
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.
-
Follow the procedure click '4' click 'sqrt' click '-'(Minus sign) click '2' Answer should be 0 But It comes back with '-8.1648465955514287168521180122928e-39' answer ;P [Edit] Tested with XP and Seven _[/More Edit] Windows Server 2008 R2 comes same with yet another answer '-1.068281969439142e-19' _[/More Edit] [/Edit]
Rating is Always appreciated.
Regards,
Hiren Solanki.
Indian Forum | My Articles | My Profile
"You will always find me near 127.0.0.1"
modified on Monday, November 1, 2010 7:00 AM
On Windows Server 2008 R2 it gives the first answer in scientific mode, and the second in standard mode.
-
Follow the procedure click '4' click 'sqrt' click '-'(Minus sign) click '2' Answer should be 0 But It comes back with '-8.1648465955514287168521180122928e-39' answer ;P [Edit] Tested with XP and Seven _[/More Edit] Windows Server 2008 R2 comes same with yet another answer '-1.068281969439142e-19' _[/More Edit] [/Edit]
Rating is Always appreciated.
Regards,
Hiren Solanki.
Indian Forum | My Articles | My Profile
"You will always find me near 127.0.0.1"
modified on Monday, November 1, 2010 7:00 AM
It works (well, the bug works) with any number. I tried sqrt(25) - 5 and sqrt(9) - :^)
-
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
Can you enlighten those of us who may not be as well-informed as you?
-
Follow the procedure click '4' click 'sqrt' click '-'(Minus sign) click '2' Answer should be 0 But It comes back with '-8.1648465955514287168521180122928e-39' answer ;P [Edit] Tested with XP and Seven _[/More Edit] Windows Server 2008 R2 comes same with yet another answer '-1.068281969439142e-19' _[/More Edit] [/Edit]
Rating is Always appreciated.
Regards,
Hiren Solanki.
Indian Forum | My Articles | My Profile
"You will always find me near 127.0.0.1"
modified on Monday, November 1, 2010 7:00 AM
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!
-
Actually, Calc internals have been replaced (around XP) with a long numbers library, so it is somehow noteworthy that this isn't enough. OTOH, the OP failed to notice tha 8e-39 is zero enough when playing around with square roots of 2.
Agh! Reality! My Archnemesis![^]
| FoldWithUs! | sighist | WhoIncludes - Analyzing C++ include file hierarchyIt needs to do it like HP calculators have always done.
-
It needs to do it like HP calculators have always done.
How did they?
Agh! Reality! My Archnemesis![^]
| FoldWithUs! | sighist | WhoIncludes - Analyzing C++ include file hierarchy -
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!
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)
0also 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.00000000000000000000000000000000000000000000000000000000000Well... it's a M$ Numpyts! :-D
-
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)
0also 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.00000000000000000000000000000000000000000000000000000000000Well... it's a M$ Numpyts! :-D
-
Yup confirmed - happening on Windows 7.
The funniest thing about this particular signature is that by the time you realise it doesn't say anything it's too late to stop reading it. My latest tip/trick Visit the Hindi forum here.
Ja ja, in W2K8 the same -8,1648465955514287168521180122928e-39 :) I think someone forgot clear the stack
Juan Pablo G.C. Overrider Blog
-
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!
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.
-
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.
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 :)
-
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 :)
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.
-
Another fails the knowledge about floating point.... When will they ever learn????? Edit: It seems to happen with any rounding around 0. If your result is not 0, the result is correctly rounded, but with values very near 0, it simply 'forgets'.... Edit 2: Press = again, the answer will be -2 as expected confirming the previous value is not rounded correctly, but still good enough due to its 'smallness' (e-39 is very small).
((λ (x) `(,x ',x)) '(λ (x) `(,x ',x)))modified on Monday, November 1, 2010 7:07 AM
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.
-
How did they?
Agh! Reality! My Archnemesis![^]
| FoldWithUs! | sighist | WhoIncludes - Analyzing C++ include file hierarchyDo everything in high precision normalised BCD instead of IEEE binary floating point types.
-
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 :)
"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." So if it isn't a bug, (the code being correct), where does the rounding error come from? Must be those damn wood elves fiddling with my computer again. Sounds like a pre-scripted response you came up with to throw off clients questioning your shoddy coding.