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: Compile and Total**

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

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

**Solve never calls Equal?**