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
>>
>>
>>
>>
>>>
>>>
>>
>>
>>
>
>
>
>
- References:
- Re: Numerical accuracy/precision - this is a bug or a feature?
- From: "Christoph Lhotka" <christoph.lhotka@univie.ac.at>
- Re: Numerical accuracy/precision - this is a bug or a feature?