MathGroup Archive 2011

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

Search the Archive

Re: Numerical accuracy/precision - this is a bug or a feature?

Dear group!

The number of posts has already become too large to read every of them, so
I appologize if I repeat something which is already said but I think some
people would like to see Equal to behave like SameQ.

Some now might think it is too much to write

In[1]:= 1.4===14/10
Out[1]= False

instead of:

In[2]:= 1.4==14/10
Out[2]= True

so one way would be to overwrite Equal itself:

In[2]:= Unprotect[Equal]
Out[2]= {Equal}

In[3]:= Equal[a_,b__]:=SameQ[a,b]

In[4]:= Protect[Equal]
Out[4]= {Equal}

In[5]:= 1.4==14/10
Out[5]= False

My question is: how dangerous is it to overwrite such a fundamental
function as Equal?



On 14/07/2011 11:20, Richard Fateman wrote:
> On 7/13/2011 12:13 AM, Bill Rowe wrote:
>> On 7/12/11 at 6:59 AM, slawek at (slawek) wrote:
>>> U=C2=BFytkownik "Oleksandr Rasputinov"<oleksandr_rasputinov at>
>>> napisa=C2=B3 w wiadomo=C2=B6ci grup
dyskusyjnych:iv6h68$s97$1 at
>>>> considered too verbose), I do not think Mathematica's way of doing
>>>> things is particularly arbitrary or confusing in the broader
>>>> context of
>>> If  1.4 is not the same as 14/10, then Mathematica should evaluate
>>> 1.4 == 14/10 as False.
>> The documentation for Equal (==) specifically states:
>> Approximate numbers with machine precision or higher are
>> considered equal if they differ in at most their last seven
>> binary digits (roughly their last two decimal digits).
> You mean "considered Equal[] by Mathematica.
>> Since the exact value 14/10 differs from less than the last
>> seven bits of the binary representation of 1.4 14/10 == 1.4
>> returns true.
>> Note, by default whenever both machine precision values and
>> exact values are in the same expression, Mathematica evaluates
>> the expression as if everything was machine precision. And in
>> general this is a good thing.
>> The other choices would seem to be either leave 1.4 == 14/10
>> unevaluated or to return False.
> Clearly Rasputinov thinks that if they are not equal they should not be
> Equal.  Thus the answer is False.
>   Both seem undesirable as they
>> would likely cause far more problem than returning True as
>> Mathematica presently does.
> Actually, you are assuming users are routinely comparing floats and
> exact numbers for equality which they should not be doing anyway.
> Programmers in FORTRAN are told to not test for equality involving floats.
>   Either of the other choices would
>> certainly make expressions containing both exact and approximate
>> values much more problematic to evaluate.
> Or less, depending on what you expect for numbers.
>> Ultimately, since the developers are unlikely to change such a
>> fundamental aspect of Mathematica, the only sensible thing is to
>> understand how Mathematica does things if you want to
>> effectively use Mathematica. The alternative would be to find a
>> system that operates more to your liking.
>   It might be fun to test to see if any of your code broke if you did this:
> Unprotect[Equal]
> Equal[a_Real,b_]:= Equal[Rationalize[SetAccuracy[a,Infinity]],b]
> Equal[a_,b_Real]:= Equal[a,Rationalize[SetAccuracy[b,Infinity]]]
> For example,
> 0.1d0 is exactly p= 3602879701896397/36028797018963968
> so my new and improved Equal thinks that
> 0.1d0 and 1/10 are NOT equal,  (indeed, they differ by
> but
> 0.1d0 and p   ARE equal.
> So the question is:  would any of YOUR code break if you used this patch
> on Equal?  Really?

  • Prev by Date: Re: Numerical accuracy/precision - this is a bug or a feature?
  • Next by Date: Re: Numerical accuracy/precision - this is a bug or a feature?
  • Previous by thread: Re: Numerical accuracy/precision - this is a bug or a feature?
  • Next by thread: Re: Numerical accuracy/precision - this is a bug or a feature?