Re: Re: Re: FindRoot cannot find obvious solution

*To*: mathgroup at smc.vnet.net*Subject*: [mg48177] Re: [mg48138] Re: [mg48131] Re: FindRoot cannot find obvious solution*From*: Andrzej Kozlowski <akoz at mimuw.edu.pl>*Date*: Sat, 15 May 2004 03:56:39 -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> <200405150058.UAA21742@smc.vnet.net>*Sender*: owner-wri-mathgroup at wolfram.com

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

**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)

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

**Re: Re: FindRoot cannot find obvious solution***From:*Andrzej Kozlowski <akoz@mimuw.edu.pl>