[Mono-list] Why is 0.1f + 0.2f - 0.3f produces such a large error number?

[Alan]

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 <InfoSeeker002 at 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 at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-list/attachments/20160523/cb31a440/attachment.html>