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

[Alan]

You could also google for discussions about adding 0.1 and/or 0.2 multiple
times. That has fun results in every language too, for example
http://stackoverflow.com/questions/26120311/why-does-adding-0-1-multiple-times-remain-lossless

On 17 May 2016 at 13:23, Alan <alan.mcgovern at gmail.com> wrote:

> 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/966a9ed0/attachment.html>