[Date Index]
[Thread Index]
[Author Index]
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**
| |