Re: bug in IntegerPart ?
- To: mathgroup at smc.vnet.net
- Subject: [mg47917] Re: bug in IntegerPart ?
- From: ancow65 at yahoo.com (AC)
- Date: Fri, 30 Apr 2004 19:26:55 -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> <c6qamj$s6j$1@smc.vnet.net>
- Sender: owner-wri-mathgroup at wolfram.com
Daniel Lichtblau <danl at wolfram.com> wrote in message news:<c6qamj$s6j$1 at smc.vnet.net>...
> 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
We already agreed that 'decimal' != 'approximate' (at least in
mathematics).
> 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
You apparently have problems to distiguish number from its internal
Mathematica representation. It seem like you don't care what a user
may need. I can replace 1.2343 by 12343/10000 to get an exact
representation. However, if the set of data is large that causes some
pain.
> 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.
This statement is misleading at best. Eventually everything is
represented by computers in binary form. 12343/10000 can be
represented with finite number of bits and so can 1.2343. To be
truthful you should say: "The numerical engine of Mathematica, as
currently implemented, leads to non terminating binary representations
of decimals."
>
>
> >>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.
We would save time and bandwidth, if you would stop pretending that
you don't understand what I'm saying, step out of your box, and admit
that there better alternatives exist.
>
>
> >>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.
You don't need to explain me how your model 'works'. I do understand
it. I am suggesting a change to something better and less confusing.
>
>
> > Only in Mathematica 1.3 is not 13/10.
>
> That's an extremely incorrect remark. In any system that does
Oh boy, here we go again. In mathematics these two numbers ARE
IDENTICAL. Fact that in your implementation they are not, should give
you hint that there might be something not as perfect as you seem to
believe. You should try to get as close to mathematics as possible.
> 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.
THAT NUMBER IS NOT APPROXIMATE. YOU MAKE IT APPRIOXIMATE BY CHOOSING A
PARTICULAR IMPLEMENTATION FOR YOUR NUMERICAL ENGINE.
>
>
> > 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.
You could look int your source code.
> Nor do I see any relevance. It's just a formatting wrapper, and as such
> has little actual mathematical content. Use RealDigits.
In that case, why do you keep such useless function in the system?
>
>
> 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 ?