Tim Barcz

Tim, the problem is that 0.16 is not the "real" value of the float either.  The real value of the float is, in fact, 0.159999996423721, since IEEE floating point numbers can't exactly store 0.16 (ever).  At least, the value I get from Excel is: 0.159999996423721.

The floating point string formatting routines in .NET and other languages are "smart" and actually show this as 0.16, but in reality that is the value that's in the 32-bit IEEE number.

That said, when you convert to double, you get 29 more 'digits' of accuracy (29 more bits, actually), and so these all get filled with zeros (since there's no way for .NET to know that you meant 0.16 when you "said" 0.159999996423721.

Hopefully this helps.  If you want more details you can check Wikipedia's Single_precision and Double_precision pages.

I also have a spreadsheet that does these calculations in Excel if you're interested in seeing the details.  I can post it on my blog if there's interest.

Kelly is right. The precision is not getting lost in the conversion. The problem is that 0.159999996423721 is the best possible float representation of 0.16.

Tim, I went through this a while back and was disappointed to find that Kelly is right. If you absolutely require 0.16, the only way to get that, is to use decimal d = 0.16.

If you translate this to base 10, and assume that a float is 3 significant figures and double is 6, then the following would be similar:

float f = 1/32f;         // f = 1.56 * 10^-2

double d = 1/32d;  // d = 1.56250 * 10^-2

Assert.That(f, Is.Equal(d));

Sure, the float gets converted to a double, but that means the expanded float is 1.56000, which clearly isn't 1.56250, and the assertion fails.

It's always best to compare the absolute difference being smaller than a threshold than equality when talking about floats.. Even something simple like:

float f = 0;

for (int i=0; i<100; i++)

 f += 0.1f;

Assert.That(f, Is.Equal(10.0f));

would fail, but for different reasons.

Reflecting my comments in binary,

.16 (decimal) = .0010100011110101110000101001 (binary), exactly

This gets stored in a floating point as:

[1.]01000111101011100001010 x 2^-3

And stored in double as:

[1.]0100011110101110000101001 x 2^-3

When the float gets promoted to double, it can't know about the extra digits.

> why isn't d = 0.16 (double) returning the same value

because double d = 0.16D also ISN'T 0.16.  Think about it this way.  If I asked you to store 1/7 in decimal in 20 digits, then write it to disk, then read it from disk, and convert it to 40 digits, would it match the result if I told you to store 1/7 in 40 digits in the first place?  The point is, by the time you 'store' 1/7 in a specified number of decimal digits, you have truncated it to something other than 1/7.  Then, when you convert it to some other number of digits, you've already lost the 'real' value so there's no way to know exactly how you're supposed to convert it.

Does this make sense?

BTW, I forgt to mention (clearly) that

double d = 0.16

is also not 0.16.  It's 0.16 - 2.22E-16 approximately.

this means that if you were to do something like come up with a 'real' way to compute 0.16 using numbers that CAN be precisely represented in double precision numbers, and you did this math inside the floating point support for the CPU (which uses 10 byte - 80bit arithmetic internally), and then loaded your 0.16 from the 8-byte (64bit) number and subtracted it, you'd get a number that isn't zero...

In other words, if you could do something like:

x = foo(a,b,c)   where a,b,c are double (IEEE 64-bit), and x is the IEEE 80-bit FPU result, then do

y = 0.16D

z = x - y

z will not be zero, due to the fact that y = 0.16D zero extends 0.16, while x is an 80-bit representation of 0.16.

Comparing floating point numbers is one of those 'looks harder than it is' issues. The usual technique is to check that the delta between them is not greater than a certain fraction. There is a pretty good summary here:

www.cygnus-software.com/.../comparingfloats.htm

This one suprises a lot of people at first.

Pick of the week: Advice For Developers On Starting An Independent Software Vendor (ISV) Business General Tips For Preparing For A Technical Presentation : Scott Hanselman shares how he prepares for technical presentations. LINQ Cheat Sheet : Brad Vincent