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>