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 >>> >>> >>> >>> >>>> >>>> >>> >>> >>> >> >> >> >> > >

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

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

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

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