WOLFRAM

Services & Resources / Wolfram Forums / MathGroup Archive

MathGroup Archive 2004

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

Search the Archive

Re: Re: Re: FindRoot cannot find obvious solution

Since my other posting somehow did not make it or at least I have not  
seen it I thought I should clarify just this one point, though I  
consider all this exchange totally without any practical significance.


>>  But that was exactly what I did in the examples with
>> Interval:
>>
>> IntervalMemberQ[Interval[1`2],0]
>> IntervalMemberQ[Sin[Interval[1`2]],0]
>>
>> How does your explanation clarify this inconsistency?
>
>

Firstly, as I wrote , this has nothing to do with interval arithmetic  
an even nothing to do with Interval.
It is simply this:


1`2==0

True


Sin[1`2]==Sin[0]

False



Why is that? Well, the answer is here:


Precision[1`2]


1.9999999999999998


Precision[Sin[1`2]]


2.1924023244417263

Sin increases Precision and 2 digits of precision seem to be the  
borderline for this problem. I can't tell with complete confidence  
exactly what the "identifying" rule is, but I do not need to know nor  
particularly want to know.

Andrzej







On 15 May 2004, at 09:58, Andrzej Kozlowski wrote:

>
> On 14 May 2004, at 13:12, Maxim wrote:
>
>> Andrzej Kozlowski <akoz at mimuw.edu.pl> wrote in message
>> news:<c7uspa$q7s$1 at smc.vnet.net>...
>>> On 11 May 2004, at 18:20, Maxim wrote:
>>>
>>>> Andrzej Kozlowski <akoz at mimuw.edu.pl> wrote in message
>>>> news:<c7klcs$2kn$1 at smc.vnet.net>...
>>>>
>>>>> makes everything work perfectly. This seems to be the case with
>>>>> almost
>>>>> every "problem" you have reported for as long as I can remember.
>>>>> (To
>>>>> deal with the remaining ones, like why 1`2 == 2  gives True, etc,
>>>>> requires only careful reading of the documentation).
>>>>
>>>> Actually this was discussed in a different thread (
>>>> http://forums.wolfram.com/mathgroup/archive/2004/Apr/msg00615.html  
>>>> ),
>>>> so I'll paste your answer from there:
>>>>
>>>> --------paste----------
>>>> Andrzej Kozlowski wrote:
>>>>
>>>> Besides it is well known that Mathematica's high precision  
>>>> arithmetic
>>>> model, based on approximate interval arithmetic,  works well only  
>>>> for
>>>> numbers whose uncertainty is much smaller than the number itself.
>>>> This
>>>> is the case in all applications I have ever heard of. For very low
>>>> precision numbers like your examples, it is known to give  
>>>> excessively
>>>> pessimistic or wrong answers, but so what?
>>>> ---------end-----------
>>>>
>>>> The statement that arbitrary-precision arithmetics in Mathematica is
>>>> based on interval arithmetics is inaccurate; perhaps we might say
>>>> that
>>>> since we have an estimate for the error, then we also implicitly  
>>>> have
>>>> an interval, but this just leads to confusion with true interval
>>>> arithmetics which is implemented for Interval objects.
>>>>
>>>> Instead, arbitrary-precision computations in Mathematica use
>>>> significance arithmetics and the notion of condition number to keep
>>>> track of precision. For example, squaring a number can lose one
>>>> binary
>>>> digit, so after calculating the square Mathematica subtracts
>>>> Log[10,2]
>>>> from the precision of the input -- it doesn't use Interval to
>>>> represent bignums and this squaring isn't performed on any  
>>>> intervals.
>>>>
>>>> Next, the suggestion that the uncertainty should be much smaller
>>>> (exactly how much that would be?) than the number itself seems to be
>>>> rather vacuous -- if the uncertainty and the number are of the same
>>>> order, that would mean that no digits are known for certain, that  
>>>> is,
>>>> the precision is zero.
>>>>
>>>> I wouldn't say that true interval arithmetics is 'known' to give
>>>> wrong
>>>> answers -- that would totally defy the purpose of intervals; the
>>>> whole
>>>> point of using them for approximate calculations is to obtain bounds
>>>> which are certain to encapsulate the possible error (so  
>>>> 'pessimistic'
>>>> and 'wrong' are more like antinomes -- pessimistic means that those
>>>> bounds might be too wide).
>>>>
>>>> But now, as far as I understand from your last post, you changed  
>>>> your
>>>> mind and instead of saying that those examples just gave meaningless
>>>> output due to low precision (which doesn't seem like a wise thing  
>>>> for
>>>> Interval to do anyway), you claim that, after reading documentation,
>>>> you can offer some explanation other than "so what?". Then please
>>>> elaborate on why 1`2==2.2, 1`2==2.3 and
>>>> IntervalMemberQ[Sin[Interval[1`2]],0] work the way they do. I'd like
>>>> to hear the explanation, that's why I was asking the question in the
>>>> first place.
>>>>
>>>> Maxim Rytin
>>>> m.r at prontomail.com
>>>>
>>>>
>>>   I wrote "approximate" interval arithemtic. Mathematica's model of
>>> significnace arithemtic is an approximation to interval aithmetic.
>>> Mathemaitca uses an approximate model because real interval  
>>> arithemtic
>>> implemented via Interval is far too slow for everyday use. An
>>> approximate model rather naturally suffers form weaknesses: in
>>> Mathematica's case one of them is dealing with low precision numbers.
>>> However, if you ned to do that you can always use true interval
>>> arithemtic. As for your other question I will just cite from  the
>>> documentation for Equal:
>>>
>>>   Approximate numbers are considered equal if they differ in at most
>>> their last eight binary digits (roughly their last two decimal
>>> digits).
>>>
>>> Andrzej
>>
>> In other words, using true interval arithmetic with low precision
>> numbers is safe? But that was exactly what I did in the examples with
>> Interval:
>>
>> IntervalMemberQ[Interval[1`2],0]
>> IntervalMemberQ[Sin[Interval[1`2]],0]
>>
>> How does your explanation clarify this inconsistency?
>
>
> You are not actually using "Interval arithmetic" here. At best,you are
> using a mixture of Interval arithmetic and significance arithmetic. You
> can certainly make accurate error estimates using interval arithmetic
> with exact numbers.
>
>
> IntervalMemberQ[Interval[{1-1/100,1+1/100}],0]
> False
>   and so on.
>
> I have already answered the other question in another posting. This
> happens because Sin increases Precision (and by the way, it's not yet
> another "paradox"). No inconsistency.
>
>>  As to Equal,
>> let's count digits:
>>
>> In[1]:=
>> RealDigits[1`2, 2, 8, 1]
>> RealDigits[1`2, 2, 9, 1]
>>
>> Out[1]=
>> {{0,1,0,0,0,0,0,0},2}
>>
>> Out[2]=
>> {{0,1,0,0,0,0,0,0,0},2}
>>
>> There's some uncertainty as to how many digits to take: by default
>> RealDigits returns 7 digits, but we can ask it to give us 8 digits;
>> all the next ones will be Indeterminate. I added leading zero just for
>> alignment with RealDigits[2.2,2] and RealDigits[2.3,2], which give
>>
>> In[3]:=
>> RealDigits[2.2,2]
>> RealDigits[2.3,2]
>>
>> Out[3]=
>> {{1,0,0,0,1,1,0,0,1,1,0,0,1,1,0,0,1,1,0,0,1,1,0,0,1,1,0,0,1,1,0,0,1,1, 
>> 0
>> ,0,1,
>>     1,0,0,1,1,0,0,1,1,0,0,1,1,0,1,0},2}
>>
>> Out[4]=
>> {{1,0,0,1,0,0,1,1,0,0,1,1,0,0,1,1,0,0,1,1,0,0,1,1,0,0,1,1,0,0,1,1,0,0, 
>> 1
>> ,1,0,
>>     0,1,1,0,0,1,1,0,0,1,1,0,0,1,1,0},2}
>>
>> If the eight-digits rule applies here, 1`2 is either equal to anything
>> (eight digits is all we know) or unequal both to 2.2 and 2.3 by the
>> leading digit. Perhaps some more 'careful reading of documentation' is
>> required?
>>
>> Maxim Rytin
>> m.r at prontomail.com
>
>
> As I wrote in my other posting, the actual rule is probably based on
> Precision and not exactly the number of digits, which only roughly
> corresponds to it. The exact rule for identifying "close" approximate
> numbers is not given because nobody needs it.
> In any case, as I wrote before,  significance arithmetic does not work
> well with low precision numbers and that is the price one pays for it
> being manageable fast. If you need error estimates for low precision
> computations use(exact!) interval arithmetic.
>
>
>
> Andrzej Kozlowski
> Chiba, Japan
> http://www.mimuw.edu.pl/~akoz/
>
>
  • Prev by Date: Re: Mean
  • Next by Date: A question about sort
  • Previous by thread: Re: Re: FindRoot cannot find obvious solution
  • Next by thread: Re: FindRoot cannot find obvious solution