Mathematica 9 is now available
Services & Resources / Wolfram Forums
-----
 /
MathGroup Archive
2004
*January
*February
*March
*April
*May
*June
*July
*August
*September
*October
*November
*December
*Archive Index
*Ask about this page
*Print this page
*Give us feedback
*Sign up for the Wolfram Insider

MathGroup Archive 2004

[Date Index] [Thread Index] [Author Index]

Search the Archive

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



  • Prev by Date: Re: Re: Question on pattern matching
  • Next by Date: Line border
  • Previous by thread: Re: bug in IntegerPart ?
  • Next by thread: Re: bug in IntegerPart ?