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