MathGroup Archive 2005

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

Search the Archive

Re: inconsistency with Inequality testing and Floor

  • To: mathgroup at smc.vnet.net
  • Subject: [mg60143] Re: inconsistency with Inequality testing and Floor
  • From: Bill Rowe <readnewsciv at earthlink.net>
  • Date: Sun, 4 Sep 2005 03:02:08 -0400 (EDT)
  • Sender: owner-wri-mathgroup at wolfram.com

On 9/3/05 at 2:06 AM, koopman at sfu.ca (Ray Koopman) wrote:

>Bill Rowe wrote:
>>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 "==",

>Not quite. "SameQ" will still give "True" for two machine-precision
>reals even though their least significant bits differ.

You are correct. I should have read the documentation for SameQ which says two Real numbers are considered equal if the difference between them is less than the uncertainty of either. So, to get a correct comparison of two nearly identical machine precision numbers RealDigits should work.
That is:

In[1]:=
x = 1. + $MachineEpsilon; 
RealDigits[x, 2] == RealDigits[1., 2]

Out[2]=
False

Admittedly, this is less convienent than using SameQ. But it is clearly possible to perform a comparison of two machine precision numbers and return False if they are not identical.
--
To reply via email subtract one hundred and four


  • Prev by Date: Re: Timing loop For !!
  • Next by Date: Re: my wish list for Mathematica next major version
  • Previous by thread: Re: inconsistency with Inequality testing and Floor
  • Next by thread: Set not-defeult options