Re: Re: FindRoot cannot find obvious solution

*To*: mathgroup at smc.vnet.net*Subject*: [mg48092] Re: [mg48085] Re: FindRoot cannot find obvious solution*From*: Andrzej Kozlowski <akoz at mimuw.edu.pl>*Date*: Thu, 13 May 2004 00:08:18 -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>*Sender*: owner-wri-mathgroup at wolfram.com

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

**References**:**Re: FindRoot cannot find obvious solution***From:*ab_def@prontomail.com (Maxim)

**Re: FindRoot cannot find obvious solution***From:*ab_def@prontomail.com (Maxim)