MathGroup Archive 2011

[Date Index] [Thread Index] [Author Index]

Search the Archive

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


  • Prev by Date: Re: How can I get better solution for this...?
  • Next by Date: Re: Insoluble marbles-in-urn problem?
  • Previous by thread: Re: Numerical accuracy/precision - this is a bug or a feature?
  • Next by thread: Re: Numerical accuracy/precision - this is a bug or a feature?