Re: Numerical accuracy/precision - this is a bug or a feature?

*To*: mathgroup at smc.vnet.net*Subject*: [mg120051] Re: Numerical accuracy/precision - this is a bug or a feature?*From*: Daniel Lichtblau <danl at wolfram.com>*Date*: Thu, 7 Jul 2011 07:29:50 -0400 (EDT)*References*: <ius5op$2g7$1@smc.vnet.net> <ius7b6$30t$1@smc.vnet.net> <iuukrt$erd$1@smc.vnet.net>

On Jul 5, 4:17 am, "slawek" <sla... at host.pl> wrote: > U ytkownik "Kevin J. McCann" <k... at KevinMcCann.com> napisa w wiadomo ci grup > dyskusyjnych:ius7b6$30... at smc.vnet.net... > > > The answer to this puzzle is that the N[2.0,20] is 2.0, not > > 2.00000000... Try N[2,20] and all is well. I think that when you put 2.0 > > in you have already limited yourself to machine precision, and N[2.0,20] > > is then just machine accuracy. > > It is still a-bug-and-a-feature. > And this bug make Mathematica nearly useless in numerical computations. "MS > Windows Calculator" is much more reliable! I have used Mathematica for numerical computation for nearly 20 years and will say that on most days I do not find it to be useless. I am not familiar with MS Windows Calculator so cannot comment on any comparison between the two. > The number of written digits IS NEITHER the precision NOR the accuracy. > Mathematica treat 2.0 as a 2.0+-0.1, but it is not the proper way to handle > numbers. As written this is not correct. In Mathematica if you input 2.0 then it is treated as a machine double, which on all platforms today has around 16 decimal places. In any case it is 2. +-$MachineEpsilon. The formatting of machine floats attempts (I believe always successfully) to show the decimal approximating to the underlying binary value (that is, within half an error-in-the-last place) that has the least number of digits. So for example 2.1 will be printed as 2.1, even though the underlying binary representation is not identically equal to 21/10. > I know, that it is common mistake to treat 2.0 as "not an integer number" > and/or "exact" number, but 2.0 is an integer number AND also it is a > rational number AND also a real number AND also a complex number. This is a matter to be determined by the language semantics (for any language, not just Mathematica). A "design decision", if you will (and as another response states). You may not like the design, and you may have reasons for not liking it, or for preferring other programs. That does not make this design intrinsically wrong. > And 2.0 is > simply 1+1+ 0/10 . Therefore, as you see, there is no "roudning", "limited > precision", "error" or "uncertinaity". It is only a matter of a notation of > decimal fractions. And decimal fractions are exact. This is only true if the underlying representation is decimal. In some programs that might be the case. In Mathematica underlying representations are binary based. So a decimal such as 2.1 will not be 2 + 1/10 because that cannot be supported by finite binary representation. A different tack would be to translate, at parse time say, decimal input such as 2.1 to exact input such as 21/10. I will spare anyone who has read this far from all the reasons why that would be an incredibly bad idea. Suffice it to say that if one wants to work with exactly 21/10 then one should use 21/10, and not an approximate input variant thereof. > Any "tolerance" is not > indicated in any way by this notation. Thus it is a bug. Nasty, big, fat bug > in the core of Mathematica. > > Even from "CS view" 2.0 is translated to IEEE representation with 56-bits of > the mantisa. Nobody declare float x = 2.0000000000 to iniject the float > point two into a code. > > slawek Daniel Lichtblau Wolfram Research

**Re: How can I get better solution for this...?**

**Re: Insoluble marbles-in-urn problem?**

**Re: Numerical accuracy/precision - this is a bug or a feature?**

**Re: Numerical accuracy/precision - this is a bug or a feature?**