MathGroup Archive 2011

[Date Index] [Thread Index] [Author Index]

Search the Archive

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

  • To: mathgroup at smc.vnet.net
  • Subject: [mg120265] Re: Numerical accuracy/precision - this is a bug or
  • From: "Christoph Lhotka" <christoph.lhotka at univie.ac.at>
  • Date: Fri, 15 Jul 2011 05:15:14 -0400 (EDT)

Dear Group!

I do not agree to arguments based on SetPrecision, since the function
modifies the numbers (it adds binary 0 to fill the missing binary digits
as stated in the documentation) it does not show us what a and b are. It
is
no suprise for me that in base 10 the numbers a and b are now different
(and SameQ qill return False).

If we want to see the actual form of a and b I would rather use FullForm:

a = 1.100000000000000000000000000;
b = 1.1;

FullForm/@{a,b}
{1.1000000000000000000000000000000000000000000000000000000001`27.041392685158225,1.1`}

As we can see the first number is accurate up to the 27th digit while the
second is accurate up to machine precision. Well but they are still
different!

First I was surprised that SameQ yields True but I guess that it has
something to do with Mathematica's principle to return results correct to
the lowest precision found in the expression.

So to my opinion Mathematica does the following: 1) first convert all
numbers to numbers of the lowest precision found in the expression, 2)
follow the usual evaluation chain. Am I correct? If so, SameQ yields True,
since up to machine precision both numbers are the same expression.

In another response to my post I learned that it is not a good idea to
overwrite the definition of Equal. As a conclusion I would implement the
following identity:

myEqual[a_,b__]:=And@@{SameQ@@Head/@{a,b},SameQ@@Precision/@{a,b},SameQ@@{a,b},Equal@@{a,b}}

a_\[TildeEqual]b__:=myEqual[a,b]

which also handles the issue with the comparison of different precision
numbers:

In[62]:= a\[TildeEqual]a
Out[62]= True

In[64]:= a\[TildeEqual]b
Out[64]= False

Of course the definition can be modified to your needs...

Best,

Christoph



On 15/07/2011 10:08, James Stein wrote:
> Richard, thanks for pointing this out.
> >From what you say, it seems that the documentation for SameQ is incorrect.
>
> On Thu, Jul 14, 2011 at 6:21 PM, Richard Fateman
> <fateman at eecs.berkeley.edu>wrote:
>
>> On 7/14/2011 6:22 AM, Christoph Lhotka wrote:
>>> Dear group!
>>>
>> ....
>>
>>> My question is: how dangerous is it to overwrite such a fundamental
>>> function as Equal?
>>>
>>> Best,
>>>
>>> Christoph
>>>
>> An excellent question.  Anyone who runs Mathematica in serious
>> applications could try it
>> and report back.
>>
>> Unfortunately, SameQ doesn't operate the way I suspect you think it does.
>>
>> Consider a = 1.100000000000000000000000000;   b=1.1
>>
>> SameQ[a,b]  is True.
>>
>> Yet a and b are different.  You can see this if you do
>> SetPrecision[a,100] and SetPrecision[b,100].
>>
>> 1.10000000000000000000000000000000000000117549435082228750796873653722\
>> 2245677818665556772087521508752
>>
>> 1.10000000000000008881784197001252323389053344726562500000000000000000\
>> 0000000000000000000000000000000
>>
>> RJF
>>
>>
>





  • Prev by Date: Re: Numerical accuracy/precision - this is a bug or a feature?
  • Next by Date: Re: Interpolation problems
  • Previous by thread: Re: Keeping it real
  • Next by thread: Re: Numerical accuracy/precision - this is a bug or