I am amazed that noone has had a thought on the business problem here.
In a perfect world everyone would always use ranged comparisons but unfortunately we do not live in a perfect world and there is a ton of code out there that already relies (albeit misguidedly) on operations from 1.xfloating points and I believe there will be people making the same mistakes as long as fp code is being written. To assume that it will be done right all the time in a developer environment such as C# is naive, I can assure you that every person on thsi list has made such a mistake (especially at 4 am when you have only had coffee and a bag of chips for sustanance since you got to the office at 7 am the previous morning). A great parallel can be drawn to the 1.x winforms controls and their handling of threading. Sure some people knew that you shouldn't touch controls from another thread but may people did not know (or just did it anyway) as it was at times a simple mistake that would not usually break easily. 2.0 comes out and checks are added to the controls, next thing you know it becomes a FAQ on every question / answer site on the internet. I wonder how many subtle bugs in applications were fixed by this addition? MS also created the backgroundworker for those who needed background processing but probably could not handle the complexity of threading (yes there are _many_ such people out there). Coming back to the FP narrowing .. right now there are countless systems silently having this problem. While taking the high and mighty academic route saying do it right all the time sounds great it does next to nothing to help the problem. I suggested putting a default behavior to handle narrowing automatically which some people seem to not like. I have yet to hear any intelligent discussion about the other option in the posts of adding a warning/error message to the compiler if it detects these situations (which should be fairly easy to detect) although I personally prefer letting someone decide which route is better for them as opposed to forcing a route down their throat. We have to face the fact that there are huge developer populations out there using the tool that are not well trained. Many struggle with things that others would consider basic. I have spoken with someone that said arrays are useless .. Frans gave a great example of wanting to use partial classes for business logic so "it's reusable". This is a major problem .. providing that you work alone or with a tam of good people you will probably not have too many (if any issues). But if you try to work with an average team this is the type of problem that slowly and silently corrupts your data I imagine that anyone managing a project is at this very moment wonderring if any of these types of issues wanderred into their system. On 6/5/06, gregory young <[EMAIL PROTECTED]> wrote:
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
-- 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
