Re: Numerical accuracy/precision - this is a bug or a feature?
- To: mathgroup at smc.vnet.net
- Subject: [mg120237] Re: Numerical accuracy/precision - this is a bug or a feature?
- From: "Christoph Lhotka" <christoph.lhotka at univie.ac.at>
- Date: Thu, 14 Jul 2011 21:18:30 -0400 (EDT)
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
>
>
>
>
>>
>>
>
>
>
- Follow-Ups:
- Re: Numerical accuracy/precision - this is a bug or a feature?
- From: Andrzej Kozlowski <akoz@mimuw.edu.pl>
- Re: Numerical accuracy/precision - this is a bug or a feature?