|
[Date Index]
[Thread Index]
[Author Index]
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
|