I'd take issue with your characterization of one version producing the "correct result", and the other one not.
Since you're using floating point and are casting to integers, I'd expect differences in the bottom digit to be par for the course. (Mainly because you're flooring the value rather than rounding it. If you had rounded, then bottom digit uncertainty only arises when you have insufficient precision.) You say this: >In order to have our code work properly (and to be efficient) we > need to know exactly how the compiler and the JIT intends to > optimize our code. I disagree. I would say this: We need to have realistic expectations of how our code might behave. I believe your expectations are unrealistic. Given the code you presented, you should be prepared for surprising answers. The fact that you didn't get a surprise on .NET 1.1 is just luck. Any time you cast from a float to an integer, there's going to be uncertainty in the bottom digit. Even though you may think the float should be an integer, it often won't be. Remember that casting to int is a floor operation. So if rounding errors have resulted in a value of, say, 41.99999, casting this to int will give you a result of 41, rather than 42. This means that you can typically expect the "wrong" value half the time even when the FP type you're using should have enough precision to represent the theoretically correct value accurately. Rounding to the nearest value instead of flooring does actually get you the answer you would expect here. And in this particular example, I believe it always will, because the error in this case will always be less than 0.5. So by rounding the result rather than flooring it, you'll always get the result you expect here. Of course it's easy enough to contrive an example where that's not the case - just use more significant digits than you have space for. -- Ian Griffiths http://www.interact-sw.co.uk/iangblog/ > -----Original Message----- > From: gregory young > > I usually try to avoid cross posting but I thought this was fairly > relevant > to advanceddotnet & dotnet-clr > > Lately I have been playing a bit with FP in C# (esp with the new clr > float > widenning). > > I have put some thoughts for changes to the C# compiler here > http://geekswithblogs.net/gyoung/archive/2006/06/05/80747.aspx and would > like to hear other's thought either for or against those possible changes. =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
