Search:   Namespaces Discussions .NET v1.1 Feedback

CLR Strange Computation Messages   Related Types This message was discovered on microsoft.public.dotnet.framework.clr. Responses highlighted in red are from those people who are likely to be able to contribute good, authoratitive information to this discussion. They include Microsoft employees, MVP's and others who IMHO contribute well to these kinds of discussions. Post a new message to this list... Exempo (VIP) Here is a weird error. I am doing simple addition in VB .NET 2002. Below is the code I ran from the command window. ?11075.04+1814.20 12889.240000000002 It should return simply 12889.24. Strange, but interesting to note. Moral: Make sure to do some rounding using addition in .NET 2002. This simple problem caused us some major problems in validating financial information. Reply to this message...        Pandurang Nayak hi, This is not a problem with the CLR. This is a problem with the way that VB handles additions. VB 6.0 also had this problem if I am right. Yes, in VB, you have to ensure you round to the correct decimal point to ensure that you haven't missed out the decimal part. Reply to this message...        Exempo (VIP) Ok. Maybe problem with VB. But C# seems to suffer the same problem. Here it the command window from a C# perspective. ?11075.04+1814.20 12889.2484 Very interesting, the addition still doesn't work. CLR? "Pandurang Nayak" wrote: [Original message clipped] Reply to this message...        Pandurang Nayak I agree that C# also has the problem! Piece of code:     double x = 11075.04+1814.20;     MessageBox.Show(x.ToString());     if(x == 1468.62)     {         MessageBox.Show("true");     }     else     {         MessageBox.Show("false");     } Though the result in the first message box comes as expected, the if condition evaluates to false. While doing an if comparison the values are compared bit-wise and hence it evaluates to false. The exact reason why this behavior happens is well-documented in many places. Like I told you earlier I have seen this happen before. So I dug up something for you to read up. Here's a neat article that explains the issue: http://www.yoda.arachsys.com/csharp/floatingpoint.html Reply to this message...        Exempo (VIP) Thank you for the article. "Pandurang Nayak" wrote: [Original message clipped] Reply to this message...        Jay B. Harlow [MVP - Outlook] (VIP) Exempo, You may want to consider using the Decimal type instead of Single or Double. In addition to Jon's first article: http://www.yoda.arachsys.com/csharp/floatingpoint.html He has one that discusses the Decimal type: http://www.yoda.arachsys.com/csharp/decimal.html Hope this helps Jay "Exempo" <Click here to reveal e-mail address> wrote in message news:Click here to reveal e-mail address... [Original message clipped] Reply to this message...        Fabian Schmied [Original message clipped] But don't forget that Decimal is also a floating point type, so there will also be "strange computations" when you get near the precision limits (even when doing something apparently harmless like modulus calculation, see [1]). Fabian [1] http://pluralsight.com/blogs/craig/archive/2004/06/29/1502.aspx Reply to this message...        Jay B. Harlow [MVP - Outlook] (VIP) Fabian, I would be surprised if the OPs "validating financial information" would approach the precision limits of Decimal. Never the less it is good information to know. Thanks Jay "Fabian Schmied" <REMOVETHISfabianDOTschmied@fhs-hagenbergDOTacDOTat> wrote in message news:Click here to reveal e-mail address... [Original message clipped] Reply to this message...        Fabian Schmied [Original message clipped] Yes, you're probably right :) Fabian Reply to this message...        Some One You're mistaken. .NET Decimal type implementation has nothing to do with floating point numbers. You can use some reflector tool to make sure of it. "Fabian Schmied" <REMOVETHISfabianDOTschmied@fhs-hagenbergDOTacDOTat> wrote in message news:Click here to reveal e-mail address... [Original message clipped] Reply to this message...        Jon Skeet [C# MVP] (VIP) Some One <Click here to reveal e-mail address> wrote: [Original message clipped] The implementation may have nothing to do with the System.Double and System.Single types, but that doesn't mean it's not a floating-point number. Could you give a widely-accepted definition of "floating-point type" which doesn't apply to the Decimal type? If you don't believe it's a floating-point type, what kind of type do you think it is? Fixed-point? Btw, the article Fabian was referencing is http://www.pobox.com/~skeet/csharp/decimal.html -- Jon Skeet - <Click here to reveal e-mail address> http://www.pobox.com/~skeet If replying to the group, please do not mail me too Reply to this message...        Fabian Schmied [Original message clipped] Yeah, thanks, must have deleted the footnote by accident. Fabian Reply to this message...        Fabian Schmied On Tue, 10 Aug 2004 14:53:36 +0300, Some One <Click here to reveal e-mail address> wrote: [Original message clipped] Leaving aside the modulus problem I mentioned in my previous post, which appears to be caused by floating-point inaccuracies, I got the idea of Decimal being a floating point type from Jon Skeet's article on this fact [1]. The docs seem to suggest at first glance that Decimal is fixed-point ("A decimal number is a signed, fixed-point value consisting of an integral part and an optional fractional part"), but then again they also say that "The binary representation of an instance of Decimal consists of a 1-bit sign, a 96-bit integer number, and a scaling factor used to divide the 96-bit integer and specify what portion of it is a decimal fraction", which sounds pretty much like an implementation of a floating point. Looking at the type in a reflector tool, I cannot see much, all the important methods are native. At a quick glance, the SSCLI sources seem to suggest that the second quote from the docs is correct and Decimal is a floating point type. Fabian Reply to this message...        Stu Smith "Fabian Schmied" <REMOVETHISfabianDOTschmied@fhs-hagenbergDOTacDOTat> wrote in message news:Click here to reveal e-mail address... [Original message clipped] However the scaling factor is a constant, so I think I'd call decimal fixed-point. It's made up of: 1 bit sign 80 bits whole number 16 bits fractional and I can't see how that could change without breaking a lot of existing code. Stu [Original message clipped] Reply to this message...        Jon Skeet [C# MVP] (VIP) Stu Smith <Click here to reveal e-mail address> wrote: [Original message clipped] No, the scaling factor *isn't* a constant. The scaling factor is in the range 0-28, and is specified in the value itself. [Original message clipped] Where do you get that idea from? You're suggesting there are only 97 bits of data in the System.Decimal type, but the docs for Decimal.GetBits disagree with you. -- Jon Skeet - <Click here to reveal e-mail address> http://www.pobox.com/~skeet If replying to the group, please do not mail me too Reply to this message...        Stu Smith "Stu Smith" <Click here to reveal e-mail address> wrote in message news:Click here to reveal e-mail address... [Original message clipped] Actually I'm talking utter utter rubbish. It is floating point. Sorry people. (I missed the constructor taking a scaling factor). [Original message clipped] Reply to this message...        Jon Skeet [C# MVP] (VIP) Stu Smith <Click here to reveal e-mail address> wrote: [Original message clipped] Phew :) I'm submitting a bug report to MSDN about the docs for System.Decimal, which really *shouldn't* call it a fixed-point number. Unfortunately, it goes wider than that - lots of documents (eg the C# specs) talk about "the floating point types" as if they should only include System.Double and System.Single :( -- Jon Skeet - <Click here to reveal e-mail address> http://www.pobox.com/~skeet If replying to the group, please do not mail me too Reply to this message...        Tom Dacon Inexact representation of floating-point numbers in computers has been an issue as long as computers have been using binary as their internal storage mechanism. This always comes as a surprise to anyone who has never had the opportunity to study computer architecture at the hardware level (do they even teach this any more in the computer science curriculum?). The fact is that most floating-point numbers have no exact representation in binary. Over the years, a lot of brain cells have been used up in devising binary encodings of floating-point numbers that maintain the highest possible precision, but for general-purpose computers you can only go so far and retain good performance. Most computer architectures these days use the IEEE encoding scheme. Here's a link to a Microsoft Knowledge Base article that might be of some interest. It's a tutorial on IEEE floating-point and will probably answer a lot of your questions: http://support.microsoft.com/default.aspx?kbid=42980 For more information, go to msdn.microsoft.com, and in the search box in the upper-right corner select the Knowledge Base radio button and enter search terms such as the following: precision accuracy floating point Hope this helps, Tom Dacon Dacon Software Consulting "Exempo" <Click here to reveal e-mail address> wrote in message news:Click here to reveal e-mail address... > Here is a weird error. I am doing simple addition in VB .NET 2002. Below is the code I ran from the command window. [Original message clipped] information. Reply to this message...        Jon Skeet [C# MVP] (VIP) Tom Dacon <Click here to reveal e-mail address> wrote: [Original message clipped] No, most *real* numbers have no exact representation in binary. All floating-point numbers have representation in binary, assuming that by "floating-point" you mean "floating binary point" as is normal. All rational numbers have an exact representation in *some* floating point base, of course - that's precisely what defines them as being rational numbers. What you're left with is irrationals, and the problem that using a floating point with base 2 doesn't even give you most of the rational numbers exactly. -- Jon Skeet - <Click here to reveal e-mail address> http://www.pobox.com/~skeet If replying to the group, please do not mail me too Reply to this message...        Tom Dacon [Original message clipped] I stand corrected, Jon. I've gotten into the habit over the years of using the term 'floating-point' when of course I should be using the term 'real'. Nevertheless, with that substitution I stand behind my comments. Your comments about rational numbers and their exact representations in some floating-point base calls to mind a discussion I had with one of the old timers in this biz a long time ago when I was still in school. Fred Greunberger, one of the legends of early computing, was winding down his career or had already retired and was at the time teaching an undergraduate class in computational techniques. I was one of the students. He was talking about techniques for computing pi to extremely large numbers of digits, and remarked that the distribution of digits in the fraction was random to some very high metric. I was young and thought I was real hot, and I immediately went, "Nahhhh, Fred, that's just an accident of the base we compute it in. If you did it in any other base there's no telling how random it would be." He blinked and thought about it a minute, and commented that maybe I had something there, but I never followed up on it and I doubt if he did. It was only later, way too late to play it as a trump card in that class session, that I realized that if you represented pi in base pi it would be completely non-random. As an aside, did you ever give any thought to the fact that ASCII text can be considered to represent a floating-point number in base 128? I used that fact once to do binary searching on a table of email addresses. It was a pretty interesting problem from an algorithmic standpoint, particularly when I needed to take SQL Server's collating sequence into account and ended up converting my base 128 numbers to base 70, of all things. Thank you for your useful correction and clarification. Tom Dacon Dacon Software Consulting Reply to this message...        Jon Skeet [C# MVP] (VIP) Tom Dacon <Click here to reveal e-mail address> wrote: [Original message clipped] No problem. > Nevertheless, with that substitution I stand behind my comments. As do I :) [Original message clipped] :) I would be interested to know whether the distribution of digits in pi is "very random" for all *integer* (or even rational) bases. I'd be surprised if it wasn't, somehow - but I wouldn't like to say why. What might be more interesting would be to see if it has any odd features when represented in base e, that being the other "obvious" irrational number to try. Speaking of e, that's the most "compact" form to store numbers in, I believe, according to some way of measuring compactness (something like number of the base * number of digits required to represent a number). Using base 3 would be more compact than binary - but I think it would be a while before I'd be able to do mental arithmetic in base 3 the way I can in binary :) [Original message clipped] Base 70 is nasty - any reason for not using base 64? (Using all the characters in ASCII would mean it would be hard to "see" the number - keeping it to base 64 allows a more readable/typable format.) -- Jon Skeet - <Click here to reveal e-mail address> http://www.pobox.com/~skeet If replying to the group, please do not mail me too Reply to this message...     System.Decimal System.Double System.Single System.Windows.Forms.MessageBox Ad MBR BootFX Best-of-breed application framework for .NET projects, developed by Matthew Baxter-Reynolds and MBR IT

Copyright © Matthew Baxter-Reynolds 2001-2008. '.NET 247 Software Development Services' is a trading style of MBR IT Solutions Ltd. Contact Us - Terms of Use - Privacy Policy - www.dotnet247.com