Re: Re: bug in IntegerPart ?

*To*: mathgroup at smc.vnet.net*Subject*: [mg47795] Re: [mg47769] Re: bug in IntegerPart ?*From*: Daniel Lichtblau <danl at wolfram.com>*Date*: Tue, 27 Apr 2004 04:46:43 -0400 (EDT)*References*: <c6g015$4lk$1@smc.vnet.net> <200404260641.CAA06324@smc.vnet.net>*Sender*: owner-wri-mathgroup at wolfram.com

AC wrote: > "DrBob" <drbob at bigfoot.com> wrote in message news:<c6g015$4lk$1 at smc.vnet.net>... > >>There's NO reason to be puzzled. 1.65 and 1.3 can't be represented exactly >>in binary, so of course their difference may not be exact, either. Hence the >>division problems have different numerators. > > > Your 'explanation' makes no sense whatsoever. Mathematica's binary > representations of 1.65-1.3 and 0.35 are the same. That can be seen by > comparing > BaseForm[1.65 - 1.3, 2] > with > BaseForm[0.35,2] > > The problem occurs because Mathematica changes, what is apparently > intended as an exact number, 1.65-1.3 (=0.35) to 0.34999999999999987 > but leaves 0.35 unchanged. > > Here is an additional reason for concerns. > > {Accuracy[#], Precision[#]} &[0.35] > => {16.4105, MachinePrecision} > > BaseForm[0.35, 2] > => 0.010110011001100110011 > > (n = 2^^0.010110011001100110011 ) > => 0.350000 > > Notice the unussual display of trailing zeros. > > {Accuracy[#], Precision[#]} &[n] > => {6.32163, 5.8657} > > I admit to be utterly confused by that loss of accuracy and precision. > > Additionally, a completely legitimate expression > 2^^BaseForm[0.35`, 2] > produces a syntax error message. > [...] The remarks above are a bit of a mess. First, the binary representations of (1.65 - 1.3) and .35 are not the same. This can be seen with RealDigits. In[6]:= RealDigits[1.65 - 1.3, 2] // InputForm Out[6]//InputForm= {{1, 0, 1, 1, 0, 0, 1, 1, 0, 0, 1, 1, 0, 0, 1, 1, 0, 0, 1, 1, 0, 0, 1, 1, 0, 0, 1, 1, 0, 0, 1, 1, 0, 0, 1, 1, 0, 0, 1, 1, 0, 0, 1, 1, 0, 0, 1, 1, 0, 0, 1, 0, 0}, -1} In[7]:= RealDigits[.35, 2] // InputForm Out[7]//InputForm= {{1, 0, 1, 1, 0, 0, 1, 1, 0, 0, 1, 1, 0, 0, 1, 1, 0, 0, 1, 1, 0, 0, 1, 1, 0, 0, 1, 1, 0, 0, 1, 1, 0, 0, 1, 1, 0, 0, 1, 1, 0, 0, 1, 1, 0, 0, 1, 1, 0, 0, 1, 1, 0}, -1} Second, (1.65 - 1.3) is not in any setting an "exact" number. It is unclear what is meant by the phrse "what is apparently intended as an exact number" but rest assured Mathematica is not a mind reader, the program employs documented conventions to distinguish exact from approximate numbers, and the arithmetic utilized is based upon such differences in representation. The statement about leaving .35 "unchanged" is at best misleading. The decimal value .35 that corresponds to 7/20 is not exactly representable in binary, which is the underlying base used in Mathematica internal arithmetic. Once one forms the closest binary approximant for a machine number, then .35 is in turn one of the closest decimal values to that binary, and it is the shortest. Hence it is what will be returned in InputForm. But it is not "exactly" equal to the binary representation (Use RealDigits[N[7/20,25],2] to verify this). As for the confusion about accuracy/precision of 2^^0.010110011001100110011, a simple count of the bits should help to clear it up. There are nowhere near the 53 bits used in machine arithmetic, hence the precision is far less than what would be attained with the full bit string. Daniel Lichtblau Wolfram Research

**References**:**Re: bug in IntegerPart ?***From:*ancow65@yahoo.com (AC)