Ian I will disagree with one comment here. "But I stand by what I said. If you've seen problems as a result of these changes, then what's happened is that some of you bugs just got more visible. They were bugs before but you happen to have got away with it. (Either you never fed in data that exercised the bug, or you never noticed.)"
This is incorrect .. 1.x was always in the same precision as such all examples always worked (same as if you manually performed narrowing in 2.0). This is where my real problem is (on the business case) as it is a breaking change that is a tough one to locate. Cheers, Greg On 6/20/06, Ian Griffiths <[EMAIL PROTECTED]> wrote:
...I guess I should have read this one before replying. :) > As a note for the people I am sure will say, "don't do this .. > use a precision range or round instead". ... But I stand by what I said. If you've seen problems as a result of these changes, then what's happened is that some of you bugs just got more visible. They were bugs before but you happen to have got away with it. (Either you never fed in data that exercised the bug, or you never noticed.) As to the business issue - yes, I know this kind of thing crops up all the time. I've been involved in projects where a portion of a system was re-implemented, and run against historical data to validate that the new implementation is consistent with the old implementation. Whenever floating point is involved, inconsistencies usually arise, and a lot of them turn out to be bugs in the original code... It happens. These things are bugs in the code. They were bugs before C# 2.0 shipped, and they continue to be bugs. I don't see that this justifies the changes you propose to the compiler. It's just one instance of a bigger and rather depressing problem: software tends to suck. I've come across far worse examples of software making horrible mistakes than this. Heck, in some of the stuff I've seen, getting to the point where floating point misuse was the biggest problem would have constituted a major quality breakthrough... What can you do about it? I think the best you can do is educate developers about floating point. Ideally that would happen before they're let loose writing FP code. But that seems not to happen in practice. Better they learn late than never. I don't see that having the compiler automatically try to mask the effects of one class of FP bug is going to help. It'll simply allow more problems to lie undetected for longer, while penalising those who get their code right. -- Ian Griffiths http://www.interact-sw.co.uk/iangblog/ > -----Original Message----- > From: Discussion of advanced .NET topics. [mailto:ADVANCED- > [EMAIL PROTECTED] On Behalf Of gregory young > Sent: 05 June 2006 21:20 > To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM > Subject: Re: [ADVANCED-DOTNET] FP Matn C# specific > > just to be clear ... > > As a note for the people I am sure will say, "don't do this .. use a > precision range or round instead". These are simply examples ... I am fine > with using these solutions (in fact I normally use range checks). The > problem is that code like this crops up regularly and it creates a very > subtle problem (that did not exist in 1.x). That and there are times when > you actually want (validly) to do an equivalence test on two floating > point > numbers that should have a consistent value (i.e. results of the same > calculation). *If these operations are to be disallowed, that is fine as > well .. but lets completely disallow them and have the compiler generate > an > warning/error in the circumstance.* > > Is the relevant paragraph from the post. > > I *know* the right way to do this .. unfortunately I would wager 80+% of > the > C#/VB developers do not. I also contend they should not need to know, it > distracts from the way they are actually using the tool. On one hand they > are constantly provided tools to keep them from dealing with code, on the > other they are no longer hidden from these complexities. > > > Cheers, > > Greg > > > > On 6/5/06, gregory young <[EMAIL PROTECTED]> wrote: > > > > I agree that epsilons should be used .. I stated this in my post but I > > somehow that was missed ... > > > > This does not only apply to == .. it applies to <> as well. > > > > If you prefer as an example ... > > > > > > float f = 97.09f * 100f; > > bool test = f > 97.09f * 99.999999f; > > Console.WriteLine(test); > > > > > > > > My point is that this is a breaking change from 1.x as > > an optimization (btw your code for doing with this with an epsilon would > be > > on the order of 10 times slower compared to the narrowing). Also keep in > > mind I am bringing this up not for myself but for the thousands of > people > > who will sit there and scratch their heads for a week at this code who > did > > not have such issues in 1.x. What will really get them is the fact it > only > > occurs in "production" code. No amount of debugging will ever find this > for > > them. > > > > Just to be clear, I agreee 100% that equalities should not be done (I > even > > put this in the post). I also think that if telling the compiler to do > > narrowing for you does not happen that it should fall onto the compiler > to > > tell you that you are breaking the rule to help prevent it. > > > > Keep in mind that these suggestions are focused at people who will not > > understand this discussion (in fact they would probably never read it), > > these people represent the majority of C#/VB.NET developers. Having the > > compiler check for tests such as these (and to force narrowing) is a > trivial > > task and would make their code work without them thinking about it. If > you > > don't believe the assumption on the majority of developers I invite you > to > > nearly any question/answer site. > > > > Surely more complex compiler or JIT optimizations will be coming soon .. > > at which point flags will be needed anyways. > > > > I was trying to focus on a business vs academic discussion .. I know the > > academic answer. > > > > > > > > btw: I see code atleast once a day doing equality checks between > floating > > points. > > > > Cheers, > > > > Greg > > On 6/5/06, Miguel de Icaza <[EMAIL PROTECTED]> wrote: > > > > > > Hello, > > > > > > > The root of this specific problem is breaking the commandments of > > > > floating-point: > > > > > > To complement this, I like this article: > > > > > > "What Every Computer Scientist Should Know About Floating-Point > > > Arithmetic": > > > http://docs.sun.com/source/806-3568/ncg_goldberg.html > > > > > > Miguel > > > > > > =================================== > > > This list is hosted by DevelopMentor(r) http://www.develop.com > > > > > > View archives and manage your subscription(s) at > > > http://discuss.develop.com > > > > > > > > > > > -- > > If knowledge can create problems, it is not through ignorance that we > can > > solve them. > > > > Isaac Asimov > > > > > > -- > If knowledge can create problems, it is not through ignorance that we can > solve them. > > Isaac Asimov > > =================================== > This list is hosted by DevelopMentor(r) http://www.develop.com > > View archives and manage your subscription(s) at > http://discuss.develop.com =================================== This list is hosted by DevelopMentor(r) http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
-- If knowledge can create problems, it is not through ignorance that we can solve them. Isaac Asimov =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
