MathGroup Archive 2011

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

Search the Archive

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

  • To: mathgroup at smc.vnet.net
  • Subject: [mg120263] Re: Numerical accuracy/precision - this is a bug or a feature?
  • From: Andrzej Kozlowski <akoz at mimuw.edu.pl>
  • Date: Fri, 15 Jul 2011 05:06:11 -0400 (EDT)
  • References: <201107150118.VAA23606@smc.vnet.net>

Well, here is one example of what would happen:

In[3]:= Unprotect[Equal]

Out[3]= {Equal}

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

In[6]:= Protect[Equal]

Out[6]= {Equal}

In[7]:= Solve[3 x  == 1, x]

Out[7]= {}

Doesn't look like a great idea to me.

Andrzej Kozlowski




On 15 Jul 2011, at 03:18, Christoph Lhotka wrote:

> 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?
> 
> Best,
> 
> Christoph
> 
> 
> 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 host.pl (slawek) wrote:
>>> 
>>>> U=C2=BFytkownik "Oleksandr Rasputinov"<oleksandr_rasputinov at hmamail.com>
>>>> napisa=C2=B3 w wiadomo=C2=B6ci grup
> dyskusyjnych:iv6h68$s97$1 at smc.vnet.net...
>>>>> 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
> 1/180143985094819840)
>> 
>> 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?
>> 
>> RJF
>> 
>> 
>> 
>> 
>>> 
>>> 
>> 
>> 
>> 
> 
> 
> 
> 



  • Prev by Date: Re: Compile and Total
  • 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: Solve never calls Equal?