MathGroup Archive 2002

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

Search the Archive

Re: Re: Accuracy and Precision

  • To: mathgroup at smc.vnet.net
  • Subject: [mg37000] Re: [mg36983] Re: Accuracy and Precision
  • From: Daniel Lichtblau <danl at wolfram.com>
  • Date: Sun, 6 Oct 2002 05:32:36 -0400 (EDT)
  • References: <anggkb$prg$1@smc.vnet.net> <200210040901.FAA04662@smc.vnet.net>
  • Sender: owner-wri-mathgroup at wolfram.com

Peter Kosta wrote:
> 
> The more I play with the example the more depressing it gets. Start
> with floating point numbers but explicitely arbitrary-precision ones.
> 
> In[1]:=
> a=77617.00000000000000000000000000000;
> b=33095.00000000000000000000000000000;
> 
> In[3]:=
> \!\(333.7500000000000000000000000000000\ b\^6 + a\^2\ \((11\ a\^2\
> b\^2 - \
> b\^6 - 121\ b\^4 - 2)\) + 5.500000000000000000000000000000\ b\^8 +
> a\/\(2\
>             b\)\)
> 
> Out[3]=
> \!\(\(-4.78339168666055402578083604864320577443814`26.6715*^32\)\)
> 
> In[4]:=
> Accuracy[%]
> 
> Out[4]=
> -6
> 
> Due to the manual section 3.1.6:
> 
> "When you do calculations with arbitrary-precision numbers, as
> discussed in the previous section, Mathematica always keeps track of
> the precision of your results, and gives only those digits which are
> known to be correct, given the precision of your input. When you do
> calculations with machine-precision numbers, however, Mathematica
> always gives you a machine­precision result, whether or not all the
> digits in the result can, in fact, be determined to be correct on the
> basis of your input. "
> 
> Because I started with arbitrary-precision numbers Mathematica should display
> only those digits that are correct, that is none.

No, 26 digits are correct (check Precision instead of Accuracy to see
this).

You appear to be showing output in InputForm. If you use OutputForm or
StandardForm only 26 digits will be shown.

                                       32
Out[3]= -4.7833916866605540257808360 10

InputForm is showing more because it exposes "bad" digits as well as
good ones.


> To relax a bit, set a new input cell to StandardForm and type
> 77617.000000000000000000000000000000000
> 
> Convert it to InputForm. You get
> 77616.999999999999999999999999999999999999999999952771`37.9031
> 
> Convert back to StandardForm
> 77616.99999999999999999999999999999999999999999976637`37.9031
> 
> Again to InputForm
> 77616.99999999999999999999999999999999999999999963735`37.9031
> 
> Back to StandardForm
> 77616.99999999999999999999999999999999999999999951376`37.9031
> 
> See what you can get if you have enough patience or a small program.
> 
> PK

Agreed, it's not very pretty. I am uncertain as to whether this
indicates a bug in StandardForm or elsewhere in the underlying numerics
code, and will defer to our numerics experts on that issue. My guess is
it is a bug if only because it violates the spirit of IEEE arithmetic
wherein floats that have integer values should be representable as such
(or something to that effect). I will point out, however, that the two
numbers in question are equal to the specified precision. Also it
appears to be improved in our development kernel.


Daniel Lichtblau
Wolfram Research


  • Prev by Date: Re: RE: RE: Accuracy and Precision
  • Next by Date: Significance Arithmetic
  • Previous by thread: Re: Accuracy and Precision
  • Next by thread: RE: RE: Accuracy and Precision