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