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

Re: inconsistency with Inequality testing and Floor

• To: mathgroup at smc.vnet.net
• Subject: [mg60102] Re: inconsistency with Inequality testing and Floor
• From: Bill Rowe <readnewsciv at earthlink.net>
• Date: Fri, 2 Sep 2005 04:33:04 -0400 (EDT)
• Sender: owner-wri-mathgroup at wolfram.com

On 9/1/05 at 2:13 AM, fateman at eecs.berkeley.edu (Richard J. Fateman)
wrote:

>Andrzej Kozlowski wrote:


>>You cannot expect inexact numbers, particularly "borderline cases"
>>as in this example, to obey the usual laws of arithmetic.

>These inconsistencies are not inherent in computer arithmetic, even
>floating-point arithmetic. They represent choices made by the
>designers of Mathematica.  In particular, choosing to allow two
>distinct numbers to be numerically equal leads to problems. I
>wonder if there is some compensating good reason for this choice in
>Mathematica. I am not aware of any reason good enough to justify
>this.

I've no idea as to why Mathematica was designed in this manner, but generally when I am using machine precision numbers it is to model the real world in some way. My knowledge (i.e., measured data) never has sufficient precision to argue two numbers within 8 binary bits of each other are distinct. So, I much prefer in these cases Mathematica treats them as equal.

However, I can see where this behaviour would cause problems in other applications. And for those applications, the solution is to use "===" rather than "==", i.e.,

In[1]:= x = 1 - 2/10^$MachinePrecision
Out[1]= 0.9999999999999998

In[2]:= 1. == x
Out[2]= True

In[3]:= 1. === x
Out[3]= False

>Calling a bug a feature does not fix it.

Nor is it valid to call something a bug when it performs as documented.
--
To reply via email subtract one hundred and four