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

Re: Re: bug in IntegerPart ?

• To: mathgroup at smc.vnet.net
• Subject: [mg47864] Re: [mg47850] Re: bug in IntegerPart ?
• From: Daniel Lichtblau <danl at wolfram.com>
• Date: Thu, 29 Apr 2004 03:05:13 -0400 (EDT)
• References: <c6l8dj$isr$1@smc.vnet.net> <200404281056.GAA12304@smc.vnet.net>
• Sender: owner-wri-mathgroup at wolfram.com

AC wrote:
> Bill Rowe <readnewsciv at earthlink.net> wrote in message news:<c6l8dj$isr$1 at smc.vnet.net>...
> 
>>On 4/26/04 at 2:41 AM, ancow65 at yahoo.com (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]
>>
>>BaseForm isn't doing what you think and will not show the difference. BaseForm controls only the display of a number. By default Mathematica displays a number to 6 significant digits. Both 1.65 - 1.3 and .35 are the same to 6 significant digits. Consequently, these will display the same when using BaseForm.
>>
>>To see the difference use RealDigits or FullForm. Both of these clearly show the difference between 1.65 - 1.3 and .35.
> 
> 
> The decimal numbers (1.65 - 1.3) and .35 are identical. The way
> Mathematica performs subtraction makes them different.

That the decimal values are identical is of course correct. So any 
program that uses an underlying decimal representation will recognize 
that they are identical.

But most programs do not use decimal for underlying representation of 
approximate numbers. In the case of machine doubles, this is because it 
does not map well to hardware arithmetic, hence is slow. Once one 
recognizes that the underlying representation is binary, well, that 
horse has been sufficiently flogged in this thread.


> When I type 0.35, Mathematica assumes the machine precision. 
> 
> Precision[0.35]
> => MachinePrecision
> 
> % // N 
> => 15.9546
> 
> Isn't that natural to expect similar for binary numbers?

I do not understand this question/remark. If it refers to

BaseForm[1.65 - 1.3, 2]

then what you have is a machine number, and a formatting "wrapper" 
requesting to show some representation of it in base 2.


> [...]
> And, I guess, you don't see any problems with these three inputs 
>  0.350000000000
>  N[0.350000000000, 6]
>  0.35`2
> producing the same output 0.35.

They don't give the same result. The OutputForm printing is the same 
things but that is a different matter and by no means wrong (OutputForm 
was never meant to be unambiguous). Anyway, the first two give the same 
machine number (because N[] will not change a machine number to an 
arbitrary precision number; you need SetPrecision or SetAccuracy for 
that). The third produces a low precision bignum. This is all correct 
Mathematica semantics.


>>>Additionally, a completely legitimate expression
>>>2^^BaseForm[0.35`, 2]
>>>produces a syntax error message.
>>
>>The expression 2^^BaseForm[0.35, 2] isn't a legitimate expression. BaseForm puts a wrapper on the expression to control display. That is Head at BaseForm[0.35, 2] is BaseForm, not a sequence of binary digits. 
> 
> 
> BaseForm[0.35, 2] might be wrong as argument for 2^^#& but still it is
> not a syntax error.

On the contrary, it is very much a syntax error, and for good reason 
(below).


> Would you agree that the following expression
> (which also generates a syntax error) is legitimate?
> 
>   fun := 2^^# & 
> 
> What about this syntax error?
>   x=1;
>   2^^x
> 
> In better design 2^^BaseForm[0.35, 2] should return 0.35` or at
> minimum unchanged expression.
> 
> AC

First note that base^^mantissa is not some infix form for a Mathematica 
expression. It is a syntax for numbers (The Mathematica Book, Appendix 
A.2.5). What this means is that the Mathematica parser (not evaluator) 
constructs the digit string; it does not form some expression

DoubleCaret[base,mantissa]

that can later be evaluated. As the parser is not seeing something of 
the above form in all your examples, it gives an error message. Back in 
the day (when I worked on compilers, some 20 years ago), we referred to 
these as syntax errors. We still do.


Daniel Lichtblau
Wolfram Research

• References:
  • Re: bug in IntegerPart ?
    • From: ancow65@yahoo.com (AC)