Re: Numerical accuracy/precision - this is a bug or a feature?
- To: mathgroup at smc.vnet.net
- Subject: [mg120223] Re: Numerical accuracy/precision - this is a bug or a feature?
- From: Richard Fateman <fateman at cs.berkeley.edu>
- Date: Thu, 14 Jul 2011 05:20:46 -0400 (EDT)
- References: <ivjgjk$2da$1@smc.vnet.net>
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 > >