Services & ResourcesWolfram ForumsMathGroup Archive

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

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)