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

[Alan]

There's no reason you should not use it if the errors you are seeing are
within the tolerance of floating point calculation limits. If you require
more accuracy then use double instead of float. If you require perfect
accuracy then you'll have to use a special type/library which provides more
accuracy than standard float/double precision.

This is a good example of what can happen depending on what underlying CPU
instruction you end up invoking:
http://stackoverflow.com/questions/8795550/casting-a-result-to-float-in-method-returning-float-changes-result
. This is true for any language as the calculation is performed in
hardware, not in software. Some languages/compilers may provide more
explicit control on which CPU instruction you end up using and which
floating point precision mode is enabled.

Alan

On 17 May 2016 at 12:32, MarLOne <InfoSeeker002 at gmail.com> wrote:

> Thanks for the reply. The following disclosure may not have anything to do
> with explaining this but it highlights some inconsistency in .Net:
>
> I know Mono is not exactly VS (well very close as Xamarin is now part of
> Microsoft) but the following comparison is still valid and interesting:
> VS2003, 2005, 2010, 2012 all returning a delta value of -7.450581E-09
>
> Anyone with a VS2013 can help by reporting what it produces.
>
> *VS2015 (regardless Update 1 or 2) returning 0*.
>
> Also regardless on what machine and processor type (even on mac), Swift,
> Java, and C all returning 0 as expected. It seems from day one the C#
> compiler is producing this same number until it comes to VS2015.
>
> I also had a look at the IL code generated and the compiler compiles the
> constant expression so the IL code does not show any arithmetic expression.
> I guess we can blame the compiler. But I rewrite the code in such a way the
> compiler cannot compile away the value at compile time. Yet I am getting
> the
> same non-zero delta. I guess Microsoft and Mono can claim that is literally
> zero because float according to ECMA C# standard is only good to 7 digits.
> But that does not explain why the other compiler/languages have so much
> more
> accuracy.
>
> Does this mean one should not use C# when performing scientific
> calculations? The above information is interesting.
>
> If you construct a DLL or COM component using C/C++, the return value (by
> P/Invoke or COM call) will be zero. If you then enhance the DLL by
> rewriting
> it in a .Net component, the return value to a .net client is
> -7.450581E-09!!
> The same client but component developed with different languages. Is this a
> good language to deal with integration?
>
> May be that's why VS2015 took the decision to fix it. When will a mono
> compiler matching VS2015's?
>
> Leon
>
>
>
> --
> 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-tp4667837p4667848.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/20160517/9d6bbf8e/attachment.html>