BUG in Windows Calc [modified]
-
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.
-
"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.
-
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.
-
Like I said - try doing the calculation yourself, in binary (if you can manage it), and see if you get the right answer. oh and your attempt at an insult? Pathetic :)
So if the code to compute in binary is sound, then there can't possibly be anything wrong with the decimal side of the coding? Wow, you must have dozens of ready replies to throw off your clients. 'Well, I understand the Print under the main menu is not working but if you'll hit your print screen key and paste that into Paint, and then print from there, you'll see the printing routines are working spot on.'
-
So if the code to compute in binary is sound, then there can't possibly be anything wrong with the decimal side of the coding? Wow, you must have dozens of ready replies to throw off your clients. 'Well, I understand the Print under the main menu is not working but if you'll hit your print screen key and paste that into Paint, and then print from there, you'll see the printing routines are working spot on.'
-
Caslen wrote:
Not quite sure what this proves but I hope you had fun doing it!
This was just e fast test how accurate the .NET framework is, and it proved that it is possible (by M$) to do the right calculations. It is a stupid design bug in Calc. Also, when I buy a calculator I want to get the exact calculation and not an approximation. Well, I see... there is no sens to talk anymore about that.
-
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
Hiren Solanki wrote:
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 [Edit] Tested with XP and Seven _[/More Edit] Windows Server 2008 R2 comes same with yet another answer '-1.068281969439142e-19' _[/More Edit] [/Edit]
Windows XP calculator also gives '-8.1648465955514287168521180122928e-39' answer. Long term bug I guess!