Comments on: Double Imprecision In .Net http://www.gringod.com/2006/02/01/double-imprecision-in-net/ Randomised nonsense. Fri, 04 Nov 2011 08:49:25 +0000 hourly 1 http://wordpress.org/?v=3.2.1 By: gringod http://www.gringod.com/2006/02/01/double-imprecision-in-net/comment-page-1/#comment-10777 gringod Thu, 23 Mar 2006 18:14:44 +0000 http://www.gringod.com/2006/02/01/double-imprecision-in-net/#comment-10777 Just because both VB6 and VB.Net implement IEEE 754 doesn't mean that they will produce the same error on the same calculation. This is because their implementations of IEEE 754 is different. What it means is that at some point in VB6 you will find similar behaviour to that which I have outlined above in VB.Net. I think. Just because both VB6 and VB.Net implement IEEE 754 doesn’t mean that they will produce the same error on the same calculation. This is because their implementations of IEEE 754 is different.

What it means is that at some point in VB6 you will find similar behaviour to that which I have outlined above in VB.Net.

I think.

]]> By: May http://www.gringod.com/2006/02/01/double-imprecision-in-net/comment-page-1/#comment-10775 May Thu, 23 Mar 2006 12:10:54 +0000 http://www.gringod.com/2006/02/01/double-imprecision-in-net/#comment-10775 You said that : "It comes from the internal representation of Doubles in the memory, and this is not specific to .Net, all real programming languages have a data type for binary floating point numbers that exhibits this behavior." but If you can find the Double problem in .Net for a sample you can run it in VB6 for example : 4.4 * 3 = 13.2 on VB6 and 13.20000000000000001 in VB.net 132 * 0.1 = 13.2 on VB6 and 13.20000000000000001 in VB.net the Double has same precision in VB6 and VB.Net this means that the problem is from .Net. You said that : “It comes from the internal representation of Doubles in the memory, and this is not specific to .Net, all real programming languages have a data type for binary floating point numbers that exhibits this behavior.”

but If you can find the Double problem in .Net for a sample you can run it in VB6 for example :
4.4 * 3 = 13.2 on VB6 and 13.20000000000000001 in VB.net

132 * 0.1 = 13.2 on VB6 and 13.20000000000000001 in VB.net

the Double has same precision in VB6 and VB.Net this means that the problem is from .Net.

]]> By: Olivier Dony http://www.gringod.com/2006/02/01/double-imprecision-in-net/comment-page-1/#comment-10627 Olivier Dony Fri, 17 Feb 2006 22:15:40 +0000 http://www.gringod.com/2006/02/01/double-imprecision-in-net/#comment-10627 This is in fact a not so "unexpected result", even if it always suprising the first time you encounter it. It comes from the internal representation of Doubles in the memory, and this is not specific to .Net, all real programming languages have a data type for binary floating point numbers that exhibits this behavior. The technical standard for representing these numbers (IEEE 754) defines floating points numbers as basically signed integers multiplied by powers of two. When fractional, you can also consider them as integers divided by powers of two. Of course, only a few decimal numbers do have an exact representation in this standard. Therefore such data types should not be used for financial applications, and typically when decimal calculations must be done and displayed to the user. This is also the reason why there is usually a more suitable Decimal representation for such numbers in programming languages (Decimal in .NET, BigDecimal in Java, etc.). These alternative data type work with a power of ten and a given "precision", which allows them to make decimal calculations as a human would do it. However these data type are more complex, and operations on these types are usually not implemented in hardware (while IEEE754 is). That is why there is a (small) trade-off in using them, in memory and time. You can find lots of information and examples about this by googling a bit. Or read the great website about Decimals maintained by Mike Colishaw, which explains it all: http://www2.hursley.ibm.com/decimal/ (Use google's cache if it is down) This is in fact a not so “unexpected result”, even if it always suprising the first time you encounter it.
It comes from the internal representation of Doubles in the memory, and this is not specific to .Net, all real programming languages have a data type for binary floating point numbers that exhibits this behavior.
The technical standard for representing these numbers (IEEE 754) defines floating points numbers as basically signed integers multiplied by powers of two. When fractional, you can also consider them as integers divided by powers of two. Of course, only a few decimal numbers do have an exact representation in this standard.

Therefore such data types should not be used for financial applications, and typically when decimal calculations must be done and displayed to the user.

This is also the reason why there is usually a more suitable Decimal representation for such numbers in programming languages (Decimal in .NET, BigDecimal in Java, etc.). These alternative data type work with a power of ten and a given “precision”, which allows them to make decimal calculations as a human would do it.
However these data type are more complex, and operations on these types are usually not implemented in hardware (while IEEE754 is).
That is why there is a (small) trade-off in using them, in memory and time.

You can find lots of information and examples about this by googling a bit. Or read the great website about Decimals maintained by Mike Colishaw, which explains it all:
http://www2.hursley.ibm.com/decimal/
(Use google’s cache if it is down)

]]>