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: <firstname.lastname@example.org> <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
- Re: bug in IntegerPart ?
- From: email@example.com (AC)
- Re: bug in IntegerPart ?