Re: bug in IntegerPart ?

*To*: mathgroup at smc.vnet.net*Subject*: [mg47848] Re: bug in IntegerPart ?*From*: ancow65 at yahoo.com (AC)*Date*: Wed, 28 Apr 2004 06:56:49 -0400 (EDT)*References*: <c6g015$4lk$1@smc.vnet.net> <200404260641.CAA06324@smc.vnet.net> <c6l7gv$imk$1@smc.vnet.net>*Sender*: owner-wri-mathgroup at wolfram.com

Daniel Lichtblau <danl at wolfram.com> wrote in message news:<c6l7gv$imk$1 at smc.vnet.net>... > 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. No. In arithmetics the decimal numbers (1.65 - 1.3) and .35 are identical and consequently have identical binary representations. Mathematica MAKES them different because it transforms 1.65 and 1.3 into truncated binary representaions BEFORE subtraction. These representations are the true cause of problems. > > 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 Mr. Lichblau is plainly wrong here. In fact,Mathematica is a mind reader. When one writes 3.5, Mathematica reads his mind and concludes that intended number is 0.34999999999999987. > 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 Really? RealDigits[0.35] => {{3, 5, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0}, 0} RealDigits[1.65] => {{1, 6, 5, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0}, 1} RealDigits[1.3] => {{1, 3, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0}, 1} None of these numbers is exactly representable in binary but still has unchanged digits. However, when one takes the difference 1.65 - 1.3 then suddenly the change of digits occurs. RealDigits[1.65 - 1.3] => {{3, 4, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9}, 0} > 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). Mr. Lichblau took it backward. Humans DO compute in decimals. The way Mathematica represents decimal numbers internally should not be of user's concern. Instead of improving your program so that it supports the human better, you try to 'improve' the human by forcing him to calculate like a binary computer. The next step might be switching completely to the binary system starting from elementary schools. Children should learn at schools that to compute 1.65-1.3 one has to find the binary representations of the numbers with as many digits as little brains can handle, perform binary subtraction, and transfer back to decimals. Only in Mathematica 1.3 is not 13/10. The notion that when one uses the decimal point, she/he doesn't really know the number and needs to be corrected is idiotic at best, and leads to further nonsense like this one 1.65 === 1.3 + .35 is True 1.65 - .35 === 1.3 is True but 1.65 - 1.3 === .35 is False and Table[RealDigits[(i + 1.65) - (i + 1.3), 2] == RealDigits[1.65 - 1.3, 2], {i, -10, 10}] => {False, False, False, False, False, False, False, True, True, True, True, False, False, False, False, False, False, False, False, False, False} Any possible claims that your numerical model is natural or intuitive are contradicted by frequent postings like the one that started this thread. The right way to manage inexact numbers is through special notation such as ~1.3 + ~.35 = ~1.65 or 1.3... + 3.5... = 1.65... > > 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. The output forms for binary binary representations are in Mathematica righfully the same. The problem is that Mathematica returns fewer digits that is needed to be consistent with the machine precision. Hence, the loss of precision. Maybe Mr. Lichtblau can answer WHY only small fraction of avaliable bits is displayed BaseForm or alternatively, why user doesn't have control over the number of digits displayed? AC > > > Daniel Lichtblau > Wolfram Research

**Follow-Ups**:**Re: Re: bug in IntegerPart ?***From:*Daniel Lichtblau <danl@wolfram.com>

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

**Re: i don't understand mapping function over a long list**

**RE: Re: Question on pattern matching**

**Re: bug in IntegerPart ?**

**Re: Re: bug in IntegerPart ?**