> This is incorrect .. 1.x was always in the same precision as such all > examples always worked
That doesn't mean you didn't have a bug. I've heard this "it always worked" argument used by people who wrote code that modified Windows Forms controls from worker threads. Yes, it may look like it always worked, but you still have a bug there. In fact the "it worked before" argument is a pretty common excuse for not fixing a bug in all sorts of scenarios. But if you're relying on undocumented behaviour, "it worked before" doesn't really stand up. Your code was behaving the way you expected by pure fluke before. That kind of fragility is a bug - it's like having a race condition bug in your code and relying on the fact that you happen never to have encountered the race condition, rather than fixing the problem. This change in the .NET 2.0 framework are simply exposing a previously latent bug. Note that the .NET 2.0 framework's behaviour is consistent with the .NET 1.1 era ECMA spec. This means that Microsoft could have released a service pack to .NET 1.1 that introduced this same behaviour without violating the specification. (Indeed they could do so in the future.) Would you write production code that uses reflection to access private fields of classes in the .NET framework class libraries? Some people do this. They are relying on undocumented behaviour, and such code could be broken by updates to the framework that conform to the advertised specification. The FP code you present is in the same class as code that monkeys with private fields: it relies on undocumented behaviour, and can be broken by spec-compliant updates to framework. If you would regard the removal of, or change in usage of a private field in the .NET framework as a breaking change, then yes, this FP change is also a breaking change. But I think it's unreasonable to expect undocumented behaviours to remain exactly the same from one version to the next. There's a reason ECMA spec documents the fact that FP evaluation precision is "implementation-dependent" and "may vary". If you ignore this aspect of the spec, you do so at your peril. I've always regarded "/fp:precise" as meaning "my FP code is hopelessly fragile, and is chock full of bugs that would be exposed by optimization, so please give me consistency so that it at least behaves consistently." In other words it's an admission that there are serious problems in your code, and that you're papering over the cracks. Relying on this flag is a sign of unwell code. -- Ian Griffiths http://www.interact-sw.co.uk/iangblog/ > -----Original Message----- > From: gregory young > > 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: [email protected] > > > 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 =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
