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)