You really have two options: 1) Use float/double values and accept that you will get rounding errors in all trivial and/non-trivial floating point calculations. You will have to deal with this lack of precision appropriately for the type of calculation you are performing. This is not a bug, this is just how floating point works.
2) Use a higher precision/infinite precision type which will give you the higher accuracy you require, if you require it. The calculation which kickstarted this conversation contains the value '0.2' which cannot be precisely represented by a float/double. The expectation here is that you *will* have rounding errors. If you get '0' it's because you got lucky and those rounding errors just happened to get truncated to give a final value of 0. The stackoverflow link in my last email has a very thorough explanation as to exactly why non-zero errors in every calculation can give a final result with zero error. The fact that different versions of .NET produce different outputs doesn't mean much as long as the error is within the expected range. The JIT in newer releases of .NET could've started choosing a different (better/faster/whatever) codepath to implement the calculation which triggers this negligible difference. On 23 May 2016 at 13:59, MarLOne <infoseeker...@gmail.com> wrote: > Hi Alan, > > While all this is find it does not explain the following observation using > the same CPU: > VS2015 the delta is zero > > For all other VS dated back to 2003 the delta is non-zero. > > In fact my friend has shown me his code that led him to question this: > He has a web server implementing that simple expression. When the server > was > hosted in VS2015 IIS (v10) Express and in a local IIS 7.5, the results are > different. One returning perfect zero while the other the delta I have > reported. > > There is hardly any accumulated error. It seems to be MS finally decides > that the result should be zero (previously some mistake or simplistic > approach) so that it is the same as Java, Swift and C/C++. > > Something dodgy to me. My friend's web demo is pretty much the same as mine > using C/Com and .Net assembly resulting in two different values. > > For those that are using this for SCIENTIFIC calculations, I urge you to do > fine grain test them using Learning Test when moving to and from VS2015 or > Roslyn. It seems VS2015 has changed something leading to the observation. > Just to make sure the change does not have impact on it. Alternately those > developed in VS2015 but run with code developed in earlier compiler one > needs to implement floating point defensive code. > > If you have to do some SCIENTIFIC computation of running that expression or > more complex one a few hundred times, the result if not taken care of of > the > type's accuracy at each iteration, the end result will have accumulation > error that puts the end result within the precision of the type. Clearly > that is wrong and should not be so sensitive to version change of the VS. > > In fairness scientific calculation is best to be performed in Double > because > more floating point operations are performed internally in double. Doing so > with produce a number of 5.55E-017 which is the same as produced by Java > and > C. > > Rover > > > > -- > View this message in context: > http://mono.1490590.n4.nabble.com/Why-is-0-1f-0-2f-0-3f-produces-such-a-large-error-number-tp4667837p4667862.html > Sent from the Mono - General mailing list archive at Nabble.com. > _______________________________________________ > Mono-list maillist - Mono-list@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-list >
_______________________________________________ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list