[Mono-list] Why is 0.1f + 0.2f - 0.3f produces such a large error number?
alan.mcgovern at gmail.com
Tue May 17 12:25:49 UTC 2016
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
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:
> . 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.
> 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
>> I guess we can blame the compiler. But I rewrite the code in such a way
>> compiler cannot compile away the value at compile time. Yet I am getting
>> same non-zero delta. I guess Microsoft and Mono can claim that is
>> 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
>> 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
>> it in a .Net component, the return value to a .net client is
>> The same client but component developed with different languages. Is this
>> 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?
>> View this message in context:
>> Sent from the Mono - General mailing list archive at Nabble.com.
>> Mono-list maillist - Mono-list at lists.ximian.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Mono-list