Re: bug in IntegerPart ?

• To: mathgroup at smc.vnet.net
• Subject: [mg47945] Re: bug in IntegerPart ?
• From: John Doty <jpd at whispertel.LoseTheH.net>
• Date: Sun, 2 May 2004 04:50:40 -0400 (EDT)
• References: <c6g015\$4lk\$1@smc.vnet.net> <200404260641.CAA06324@smc.vnet.net> <c6l7gv\$imk\$1@smc.vnet.net> <200404281056.GAA12294@smc.vnet.net> <c6qamj\$s6j\$1@smc.vnet.net> <c6unq6\$as8\$1@smc.vnet.net>
• Sender: owner-wri-mathgroup at wolfram.com

```AC wrote:
> I have feeling speaking to deaf ears. Let me try again.

We feel the same way. Please listen.

> suggestion. (1) Treat all decimals as exact numbers. In this way
> number of problems arising on the border between Machine Precision and
> Big Number Arithmetic would disappear. The mapping between decimals in
> mathematics and Mathematica would become bijection. (2) Introduce a
> new notation or alternatively a programming switch for inexact numbers
> that would follow IEEE rules.

As a Mathematica user, I don't find this constructive. It would break
practically everything I've done in Mathematica in the last 15 years.

The notation 1.65 in Mathematica means, *by definition*, "an approximate
number within machine precision of 1.65". You may not like this
definition, but it's fundamental to the Mathematica language, and most
of us who *actually use* Mathematica find it perfectly natural. If the
number's got a "." in it, it's approximate. Period :-)

If you want an exact rational number, use 165/100. What's so hard about
that? The subset of rationals that can be expressed in decimal isn't
especially useful for exact calculation anyway.

> Both developers and users will have
> precision or speed as needed without compromising mathematical clarity
> and precision.