[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
Prev by Date:
**strange problems with Random**
Next by Date:
**RE: Re: bug in IntegerPart ?**
Previous by thread:
**Re: Re: bug in IntegerPart ?**
Next by thread:
**Re: bug in IntegerPart ?**
| |