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: [mg120264] Re: Numerical accuracy/precision - this is a bug or a feature?
  • From: "Christoph Lhotka" <christoph.lhotka at univie.ac.at>
  • Date: Fri, 15 Jul 2011 05:06:22 -0400 (EDT)

yes, indeed!

On 15/07/2011 09:34, Andrzej Kozlowski wrote:
> 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: Numerical accuracy/precision - this is a bug or a feature?
  • Next by Date: Re: Numerical accuracy/precision - this is a bug or
  • 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?