Re: Re: bug in IntegerPart ?
- To: mathgroup at smc.vnet.net
- Subject: [mg47870] Re: [mg47848] Re: bug in IntegerPart ?
- From: Daniel Lichtblau <danl at wolfram.com>
- Date: Thu, 29 Apr 2004 03:05:41 -0400 (EDT)
- References: <c6g015$4lk$1@smc.vnet.net> <200404260641.CAA06324@smc.vnet.net> <c6l7gv$imk$1@smc.vnet.net> <200404281056.GAA12294@smc.vnet.net>
- Sender: owner-wri-mathgroup at wolfram.com
AC wrote:
> Daniel Lichtblau <danl at wolfram.com> wrote in message news:<c6l7gv$imk$1 at smc.vnet.net>...
>
>> [...]
>>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.
The confusion is between arithmetic models. Mathematica uses a binary
representation for approximate numbers. It does not do (1.65 - 1.3) in
decimal arithmetic. It does not represent either operand of the
subtraction in decimal arithmetic.
> Mathematica MAKES them different because it transforms 1.65 and 1.3
> into truncated binary representaions BEFORE subtraction.
This much is correct.
>These representations are the true cause of problems.
The word "problems" is an artifice. These examples simply illustrate
well understood consequences of numeric computation when one converts
between representations in different bases, and this is not regarded as
a "problem" in the computation community. You are of course welcome to
see it as a problem but the arguments and examples purporting to show
that are not compelling.
>>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.
Um, again, that's what happens when one goes from a base with a finite
representation of a given value to one with (only) a nonterminating
representation. No mind reading; it's a consequence of Mathematica
semantics, to wit, that underlying representation is in binary. That
this is the case for machine numbers is an obvious consequence of the
fact that machine arithmetic is implemented using floating point
hardware, all of which nowadays works with binary representations.
>>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}
Again, that's because Mathematica does not use an underlying decimal
representation. It would probably be a more productive use of time and
bandwidth for you to do these RealDigits experiments using base 2. As
has been explained, that's the base actually used for purposes of
underlying representation and arithmetic.
>>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.
I don't much care whether or how you yourself choose to compute with
approximate numbers. I am simply explaining the Mathematica semantics
involved. If you choose to dislike them that's fine. But you'll need to
take a different approach if your goal is to find inconsistencies or
other flaws.
> Only in Mathematica 1.3 is not 13/10.
That's an extremely incorrect remark. In any system that does
approximate computation using an underlying binary representation (and
this is most computational math programs, I gather), 1.3 is not 13/10.
Indeed in any system that distinguishes exact from approximate numbers,
1.3 is not 13/10 (though they may be deemed numerically equal). I have
no intention of giving a lecture on the distinction between exact and
approximate arithmetic. If it is unclear to you then you can read up on
it in pretty much any text that covers symbolic algebra (as well as many
that don't).
> 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,
Nobody is being "corrected". Approximate numbers are stored in binary
representation. Period.
> 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.
Interestingly, the OPs (original postas, that is) generally come to
understand the replies. That you continue to beat the thread has but
little bearing on any aspect of Mathematica semantics or correctness.
As I said, you'll need to do some real work to find inconsistencies.
Best you've managed thus far is to complain about the consequences of
using a binary represnetation for approximate numbers, demonstrate some
amount of ignorance as to how the arithmetic works, and to make a bunch
of vague assertions as to how it "should" work. That you may wish for an
underlying decimal representation is fine. But Mathematica will not
support that wish. Possibly some other programs do.
> 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...
Whatever.
>>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
I haven't the faintest notion as to how BaseForm chooses to truncate.
Nor do I see any relevance. It's just a formatting wrapper, and as such
has little actual mathematical content. Use RealDigits.
Daniel Lichtblau
Wolfram Research
- References:
- Re: bug in IntegerPart ?
- From: ancow65@yahoo.com (AC)
- Re: bug in IntegerPart ?
- From: ancow65@yahoo.com (AC)
- Re: bug in IntegerPart ?