Re: Numerical accuracy/precision - this is a bug or a feature?
- To: mathgroup at smc.vnet.net
- Subject: [mg120053] Re: Numerical accuracy/precision - this is a bug or a feature?
- From: Daniel Lichtblau <danl at wolfram.com>
- Date: Thu, 7 Jul 2011 07:30:12 -0400 (EDT)
- References: <ius5op$2g7$1@smc.vnet.net> <ius7hm$358$1@smc.vnet.net> <iuuko3$eqi$1@smc.vnet.net>
On Jul 5, 4:15 am, Richard Fateman <fate... at cs.berkeley.edu> wrote: > In brief: yes to both. > > On 7/4/2011 4:18 AM, Kevin J. McCann wrote: > ... > > > > >> 1. N[2.0,20] should give 2 with accuracy/precision/whatsever about 20 > >> decimal digits, i.e. 2.00000000000000000000 > > WRI will defend this as a feature. > > You thought that the semantics of N[] were the same as SetPrecision > e.g. > > N[SetPrecision[2.0, 20]*N[Sqrt[2], 20], 20] > > works as you expected. > > So from your perspective, and from the perspective of anyone else who > thinks along the same lines, it is a bug. I would prefer to call it > a design error. > > 2.0 (indeed, any floating point number) is a perfectly respectable way > of denoting a number that can be expressed in higher precision by adding > binary zeros. WRI doesn't agree. > > RJF I don't think this holds up for all floats in the sense you seem to indicate. Take 2.1 for example. We can (and will) use SetPrecision to pad with binary zeroes, just as you use it above on 2.0. In[606]:= N[SetPrecision[2.1, 20]*N[Sqrt[2], 20], 20] Out[606]= 2.9698484809834997281 But this is not an accurate representation of 21/10 * Sqrt[2] to 20 places. In[607]:= N[21/10*Sqrt[2], 20] Out[607]= 2.9698484809834996025 They are off by arould a machine epsilon. No surprise here, I think. In[608]:= % - %% Out[608]= -1.256*10^-16 I also think that this sort of numeric discrepancy is inevitable* in any program that uses decimal input and binary representation. Daniel Lichtblau Wolfram Research *Perhaps more inevitable than these threads. Now that's pretty inevitable.