Re: bug in IntegerPart ?
- To: mathgroup at smc.vnet.net
- Subject: [mg47848] Re: bug in IntegerPart ?
- From: ancow65 at yahoo.com (AC)
- Date: Thu, 29 Apr 2004 00:35:00 -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
- References:
- Re: bug in IntegerPart ?
- From: ancow65@yahoo.com (AC)
- Re: bug in IntegerPart ?