Services & Resources / Wolfram Forums / MathGroup Archive

MathGroup Archive 2004

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

Search the Archive

Re: Re: FindRoot cannot find obvious solution

  • To: mathgroup at smc.vnet.net
  • Subject: [mg48138] Re: [mg48131] Re: FindRoot cannot find obvious solution
  • From: Andrzej Kozlowski <akoz at mimuw.edu.pl>
  • Date: Fri, 14 May 2004 20:58:52 -0400 (EDT)
  • References: <200404270847.EAA18892@smc.vnet.net> <c6o3lc$cd0$1@smc.vnet.net> <c6qags$s56$1@smc.vnet.net> <200405080524.BAA11690@smc.vnet.net> <c7klcs$2kn$1@smc.vnet.net> <200405110920.FAA28320@smc.vnet.net> <c7uspa$q7s$1@smc.vnet.net> <200405140412.AAA04779@smc.vnet.net>
  • Sender: owner-wri-mathgroup at wolfram.com
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: mechanical sound amplifications using a Limacon
  • Next by Date: Re: Mean
  • Previous by thread: Re: FindRoot cannot find obvious solution
  • Next by thread: Re: Re: Re: FindRoot cannot find obvious solution