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.mcgov...@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 <infoseeker...@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@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