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® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
