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

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.

>  I made a constructive
> 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.

We already have this. The notation just doesn't match your prejudices.

-jpd