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: <email@example.com> <200404281056.GAA12304@smc.vnet.net>
- Sender: owner-wri-mathgroup at wolfram.com
> 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.
> => 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
> N[0.350000000000, 6]
> 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
>>>Additionally, a completely legitimate expression
>>>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
> Would you agree that the following expression
> (which also generates a syntax error) is legitimate?
> fun := 2^^# &
> What about this syntax error?
> In better design 2^^BaseForm[0.35, 2] should return 0.35` or at
> minimum unchanged expression.
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
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.
Prev by Date:
Re: Re: FindRoot cannot find obvious solution
Next by Date:
Re: Re: Question on pattern matching
Previous by thread:
Re: bug in IntegerPart ?
Next by thread:
RE: Re: bug in IntegerPart ?