Welcome to MSDN Blogs Sign in | Join | Help

Kathy Kam

Reflection on the CLR and .NET
Partial Answer: "Double Trouble"

I am so sorry for not posting the answer to "Double Trouble" sonner. Vacation and busy work schedule has prevented me from doing so, but that's no excuse!

Before I dive it why this won't work, I have to admit, you can't really tell without compiling the program. Again, not the best written quiz,:( .... maybe I should just stop making them... but it's a fun way to discuss interesting things in the .NET Framework. What do you think?

One of the main concepts I want to highlight in that post is what Tommy (who was the first person) who posted back to my comments said:

Tuesday, May 09, 2006 2:23 AM by Tommy Carlier
No, I can't. But I have a feeling that it will say 'false' for all 4 the cases. I know that doubles and == don't like each other very much.
 
Double by definition is inexact, and doing equality comparison on it is bad news. Yes, most of the time it'll work, but as I have highlighted here. There are some random numbers where it just won't work!
 
To understand why this is happening try running dumping each of the string to a byte array like this:

 

byte[] dIncorrect = BitConverter.GetBytes(d);

byte[] dCorrect = BitConverter.GetBytes(4.170404);

You will see that the least significant bit is incorrect:
 
dIncorrect {Dimensions:[0x00000008]}
 [0x00000000] 0x2a byte
 [0x00000001] 0x6e byte
 [0x00000002] 0xdc byte
 [0x00000003] 0x62 byte
 [0x00000004] 0x7e byte
 [0x00000005] 0xae byte
 [0x00000006] 0x10 byte
 [0x00000007] 0x40 byte
dCorrect {Dimensions:[0x00000008]}
 [0x00000000] 0x2b byte
 [0x00000001] 0x6e byte
 [0x00000002] 0xdc byte
 [0x00000003] 0x62 byte
 [0x00000004] 0x7e byte
 [0x00000005] 0xae byte
 [0x00000006] 0x10 byte
 [0x00000007] 0x40 byte

The next step to the investigation is to see why the bit was parsed incorrectly, which also leads me to my real reason why I haven't posted this earlier. I want to debug down on our code to see what are the "gotcha" numbers that will cause this to be inexact. I still haven't found the time to do it yet... so I will have to post a follow up to the answer.
Posted: Monday, July 31, 2006 8:00 AM by KathyKam

Comments

Jeff Parker said:

>> maybe I should just stop making them...

Don't you dare stop making them ;-)

>> but it's a fun way to discuss interesting things in the .NET Framework. What do you think?

I think you are correct I have always enjoyed your articles as they bring up some odd and wierd behavior I never really spent a lot of time thinking about.
# July 31, 2006 12:19 PM

Ghassan said:

Double will store the number as binary
so if the decimal was translated to binary without "round-up" errors then the condition is true

but it is depends on the numbers we are representing
so some numbers will give true, and others will give false

to get a real representation of the decimal system, you should instead use Decimal

Decimal will store the number internally as decimal represetation, and that is why it is very accurate
But Decimal is slow

# August 8, 2006 1:15 PM
Leave a Comment

(required) 

(required) 

(optional)

(required) 

  
Enter Code Here: Required

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Page view tracker