MathGroup Archive 2004

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

Search the Archive

Re: FindRoot cannot find obvious solution

  • To: mathgroup at smc.vnet.net
  • Subject: [mg48131] Re: FindRoot cannot find obvious solution
  • From: ab_def at prontomail.com (Maxim)
  • Date: Fri, 14 May 2004 00:12:29 -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>
  • Sender: owner-wri-mathgroup at wolfram.com

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? 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


  • Prev by Date: RE: RE: Re: Mandelbrot Set & Mathematica
  • Next by Date: Re: got "Map" to work finally.
  • Previous by thread: Re: Re: Re: FindRoot cannot find obvious solution
  • Next by thread: Re: Re: FindRoot cannot find obvious solution