[Date Index]
[Thread Index]
[Author Index]
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
>
Prev by Date:
**RE: 34.123*89 = 3036.95 (3036.947)**
Next by Date:
**Re: bug in IntegerPart ?**
Previous by thread:
**Re: bug in IntegerPart ?**
Next by thread:
**addition of three angular momenta**
| |