[Date Index]
[Thread Index]
[Author Index]
Re: bug in IntegerPart ?
*To*: mathgroup at smc.vnet.net
*Subject*: [mg47953] Re: bug in IntegerPart ?
*From*: Bill Rowe <readnewsciv at earthlink.net>
*Date*: Sun, 2 May 2004 04:50:52 -0400 (EDT)
*Sender*: owner-wri-mathgroup at wolfram.com
On 4/30/04 at 7:26 PM, ancow65 at yahoo.com (AC) wrote:
>I can replace 1.2343 by 12343/10000 to get an exact representation.
>However, if the set of data is large that causes some pain.
Exactly correct. And it applies equally to known methods of representing any finite sequence of decimal digits other than an integer since modern cpus work in binary not decimal.
>>this is the case for machine numbers is an obvious consequence of the
>>fact that machine arithmetic is implemented using floating point
>>hardware, all of which nowadays works with binary representations.
This statement is misleading at best. Eventually everything is
represented by computers in binary form. 12343/10000 can be
represented with finite number of bits and so can 1.2343. To be
truthful you should say: "The numerical engine of Mathematica, as
currently implemented, leads to non terminating binary representations
of decimals."
Your statement is clearly incorrect. It isn't the "numerical engine of Mathematica" that leads to non terminating binary representations of decimals. The very fact Mathematica can represent 1.2343 as 12343/100000 and lose no precision whatever demonstrates the issue is not with Mathematica.
You have a choice. Use Mathematica or another software package to work with 1.2343 as an exact decimal or you can convert it to binary and work with the binary form. If you convert it to binary, then you get the maximum performance possible from whatever cpu your computer uses since this is the native form for the cpu. But no matter what software you use, the conversion process cannot be exact.
OTOH, you can work with 1.2433 in a number of ways with Mathematica or other software packages without doing the binary conversion. Then the number you are working with will be exactly 1.2343 rather than an approximation. But thehe consequence is more cpu cycles will be required as you are no longer working with numbers in the form the cpu was designed to work with.
--
To reply via email subtract one hundred and four
Prev by Date:
**Re: Fitting a Cylinder to 3D data points**
Next by Date:
**RE: Re: bug in IntegerPart ?**
Previous by thread:
**Re: bug in IntegerPart ?**
Next by thread:
**RE: Re: bug in IntegerPart ?**
| |