Re: bug in IntegerPart ?
- To: mathgroup at smc.vnet.net
- Subject: [mg47915] Re: bug in IntegerPart ?
- From: ancow65 at yahoo.com (AC)
- Date: Fri, 30 Apr 2004 19:26:54 -0400 (EDT)
- References: <c6qb7p$sdf$1@smc.vnet.net>
- Sender: owner-wri-mathgroup at wolfram.com
Bill Rowe <readnewsciv at earthlink.net> wrote in message news:<c6qb7p$sdf$1 at smc.vnet.net>... > On 4/28/04 at 6:56 AM, ancow65 at yahoo.com (AC) wrote: > > >Bill Rowe <readnewsciv at earthlink.net> wrote in message > >news:<c6l8dj$isr$1 at smc.vnet.net>... > > >>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. > > I only seen one "computer" system where this is a true statement. That was a > > HP-41 handheld calculator which used binary coded decimal arithmetic instead > of true binary. In every other system the numbers 1.65 and 1.3 are transformed > to a finite binary representation, then the subtraction is done. That is completely wrong statement. That can be done programmatically on practically any hardware. I will not give the reason to reject this posting by naming systems or languages that do that, you can ask for pointers on sci.math.symbolic. Besides, 1.65=165/100 and, as we all know, the latter is represented exactly in Mathematica. > And since neither 1.65 nor 1.3 has a finite binary representation, the result > you get from the subtraction is different than the closest machine number to > .35. Or said differently, unless you are using a system such as that used on > the HP-41 calculator, 1.65 - 1.3 is indeed not identical to 0.35 You are mixing a mathematical concept with its programatic representation. > > >The way Mathematica performs subtraction makes them different. > > This is not an issue with Mathematica. Any machine using a standard IEEE > floating point arithmetic will have the same issue. If you really need more I completely agree with you that. You are missing the fact that there are other ways to represent decimals. > details, look at any standard text on numerical analysis. > > >>Right, here you've inputed a number accurate to 6 significant > >>digits. So, Mathematica displays 6 significant digits That is not that obvious to me. When you type 1.65 mathematica interprests that decimal as a machine precision number with 16 digits or so. Why the interpretation should be any different for binary numbers? > > >BaseForm[0.35, 2] might be wrong as argument for 2^^#& but still it > >is not a syntax error. > > By definition, it is improper syntax since you got an error. What definition? The reason could be a bug in parser. > > >In better design 2^^BaseForm[0.35, 2] should return 0.35` or at > >minimum unchanged expression. > > Perhaps. But that isn't the way Mathematica is designed. Additionally, the Mathematica design is not in stone nor perfect. > documentation does reasonably clearly indicate 2^^BaseForm[0.35, 2] isn't > valid in Mathematica. The documentation says "BaseForm acts as a "wrapper", which affects printing, but not evaluation." Mr. Lichtblau and other respondents clearly pointed out that BaseForm is not useful for to print numbers in given base and that RealDigits should be used instead. If there is no clear purpose for BaseForm left, why it is not removed from the system? AC >