Mathematica 9 is now available
Services & Resources / Wolfram Forums
-----
 /
MathGroup Archive
2004
*January
*February
*March
*April
*May
*June
*July
*August
*September
*October
*November
*December
*Archive Index
*Ask about this page
*Print this page
*Give us feedback
*Sign up for the Wolfram Insider

MathGroup Archive 2004

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

Search the Archive

Re: bug in IntegerPart ?

  • To: mathgroup at smc.vnet.net
  • Subject: [mg47947] Re: bug in IntegerPart ?
  • From: Bill Rowe <readnewsciv at earthlink.net>
  • Date: Sun, 2 May 2004 04:50:42 -0400 (EDT)
  • Sender: owner-wri-mathgroup at wolfram.com

On 4/30/04 at 7:26 PM, ancow65 at yahoo.com (AC) wrote:

>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:
>>

>>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.

Not completely wrong, but not complete. Yes, one can create hardware/software to treat any sequence of decimal digits as an exact number. But this typically isn't done. And there is good reason not to do this. There are significant costs in performance. 

>>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.

Not at all. I simply reconize the arithmetic machines use is almost universally binary rather than decimal. Both are valid mathematical concepts. But there are consequences to translating a finite decimal representation to a finite binary representation just as there is for any base conversion.

>>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.

No, I am not missing that fact. In fact, there is more than one way to input numbers into Mathematica. Mathematica supports arbitrary precision numbers and exact numbers. If you specify the numbers as exact numbers you get the exact answer regardless of the base chosen. But when you do this you give up the speed advantages of doing machine arithmetic. Mathematica cannot achieve your expectations of exactness using machine precision numbers.

>>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."

See my comments regarding this in another post.

>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?

BaseForm outputs a binary number in a more human readable from than RealDigits. So, it does have a clear purpose. It is just the purpose isn't what you had in mind.
--
To reply via email subtract one hundred and four


  • Prev by Date: Re: bug in IntegerPart ?
  • Next by Date: RE: Union & Select for removing duplicates in a list
  • Previous by thread: Re: bug in IntegerPart ?
  • Next by thread: Re: bug in IntegerPart ?