Re: Re: FindRoot cannot find obvious solution

*To*: mathgroup at smc.vnet.net*Subject*: [mg48205] Re: [mg48186] Re: FindRoot cannot find obvious solution*From*: Andrzej Kozlowski <akoz at mimuw.edu.pl>*Date*: Tue, 18 May 2004 04:16:07 -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> <c83qlt$li3$1@smc.vnet.net> <200405170721.DAA29564@smc.vnet.net>*Sender*: owner-wri-mathgroup at wolfram.com

On 17 May 2004, at 16:21, Maxim wrote: > Andrzej Kozlowski <akoz at mimuw.edu.pl> wrote in message > news:<c83qlt$li3$1 at smc.vnet.net>... >> On 14 May 2004, at 13:12, Maxim wrote: >> >>> 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. >> > > But nobody says that Interval[Sin[1`2]] and Sin[Interval[1`2]] should > be identical; it's no surprise that Sin[Interval[{0,Pi}]] is not > Interval[{Sin[0],Sin[Pi]}]. > > Here's what the question was about (it seems that I have to start with > that). We create Interval[1`2]; numbers -0.29 and 2.2 belong to the > interval, therefore taking Sin of the interval we must obtain an > interval which includes at least the range from -0.28 to 1.0; > otherwise it would be like squaring Interval[{0,2}] and still getting > Interval[{0,2}] as the answer. > > Instead, Sin[Interval[1`2]] returns an interval which includes (by > IntervalMemberQ) only numbers from 0.12 to 1.0. > > It's quite plausible that, while the interval bounds are rounded > outwards as they should be, the increased precision 'eats up' this > rounding and in the end we get an interval which is narrower than > necessary. But to say that there is no inconsistency in the strict > mathematical sense is incorrect. > >>> 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. > > We've been through that before: if equality is determined by the > precision of the number (that would be explanation #4 or so by now?), > then only numbers in the range from 1-0.01 to 1+0.01 should be > considered as equal to 1`2. > > Maxim Rytin > m.r at prontomail.com > > > This is argument is clearly not getting anywhere, and as it concerns matters of so little significance that nobody else is likely to pay attention to it, this is defintely my last response. I never wrote that if equality is determined by the precision of the number in the sense of interval arithmetic, because significance arithemtic only approximates interval arithmetic. And by interval arithmetic I mean what everybody except you means by interval arithmetic: exact interval arithemtic. I do not know what the hybrid one inplemented in Matheamtica is for, it seems ot me just a byproduct of something. The actual situation is this: 1. Mathematica has a fully implemented exact interval arithemtic. It is fully logically self-consistent (barring bugs) and the fact that such arithmetic must be in certian ways quite unlike ordinary arithmetic . It is in fact "pessimistic" in the sense I described in another thread that you started by claiming that a perfectly sensible answer was wrong. (Since you seem to know very little about these matters I suggest looking at 97 of "Structure and Interpretation of Computer Programs" by Abelson and Sussman and solving problem 2.16. I would certainly be interested in seeing your solution.) In any case, exact interval arithmetic can be used to give bounds on errors when working with low precision numbers. Fortunately most normal people do not do this very often so the slowness is not a terrible problem. 2. Mathematica has also significance arithmetic, which is an approximation to interval arithmetic. It is fast and works well in the sort of situations that most people most of the time find themselves in. It achieves this speed by "bending corners", in such a way that computations with low precision numbers are generally very unreliable and can give paradoxical results. In particular it produces the effect you have re-discovered. (If you bothered to check the archives you would have discovered that exactly the same discussion, including the example with 1`2 was held here already a few years ago). I believe that what i have written roughly corresponds to what actually happens but in any case it does not matter at all. The reason why it does not mater is that 1. You have been told that significance arithmetic is unreliable in such cases 2. As Richard Fateman pointed out the last time this issue was discussed (at least in my memory) question like: 1`2 == 2 do not make sense and there is never any reason to ask them. 3. If you can devise a system of arithmetic that has the advantages of significance arithmetic without its defects than I am sure everyone will be impressed and maybe even Wolfram will want to hire you. 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: FindRoot cannot find obvious solution***From:*ab_def@prontomail.com (Maxim)

**Re: Uniform design**

**Tree and Lists**

**Re: FindRoot cannot find obvious solution**

**packges for boolean stuff...**