Re: Limit and Root Objects

*To*: mathgroup at smc.vnet.net*Subject*: [mg72307] Re: Limit and Root Objects*From*: Andrzej Kozlowski <akoz at mimuw.edu.pl>*Date*: Tue, 26 Dec 2006 04:46:07 -0500 (EST)*References*: <em606c$2o1$1@smc.vnet.net> <4586C045.2020805@metrohm.ch> <DA28578F-4E16-49A8-A447-3FDE236F303F@akikoz.net>

*This message was transferred with a trial version of CommuniGate(tm) Pro* In fact, in the case of, real roots of a cubic, dealing with this problem seems even easier that in my description (I really had more complicated cases in mind). We do not really need NLimit at all. All we need to do is to find if the point at which the limit is being computed is a multiple point or not. If it is, then we need to check it the newly created real roots are smaller or larger than the root that has been before the collision the only real root. That is all that would need to be done. I think in principle one could use NLimit and significance arithmetic even to deal with the root crossing problems in the case of complex roots. Computing any directed limit could first be done numerically, then one for the finite number of possible choices of the branch could be made with certainty. I realize however that complexity considerations would argue against this. It might at least be a good idea in such cases to issue a warning and suggest that to the user to check the answer with NLimit. Andrzej Kozlowski On 19 Dec 2006, at 09:06, Andrzej Kozlowski wrote: > What you describe, including the fact that the numbering or roots > changes is inevitable and none of it is not a bug. There cannot > exist an ordering of complex roots that does not suffer from this > problem. What happens is this. > Real root objects are ordered in the natural way. A cubic can have > either three real roots or one real root and two conjugate complex > ones. Let's assume we have the latter situation. Then the real root > will be counted as being earlier then the complex ones. Now suppose > you start changing the coefficients continuously. The roots will > start "moving in the complex plane", with the real root remaining > on the real line the two complex roots always remaining conjugate > (symmetric with respect to the real axis). Eventually they may > collide and form a double real root. If this double real root is > now smaller then the the "original real root" (actually than the > root to which the original real root moved due the the changing of > the parameter), there will be a jump in the ordering; the former > root number 1 becoming number 3. > This is completely unavoidable, not any kind of bug, and I am not > complaining about it. It takes only elementary topology of > configuration spaces to prove that this must always be so. > > What I am not really convinced of is that Limit really couldn't > deal with this problem, at least partially, in the case of real > roots of cubics and quartics. I have been told that it cannot be > done because Limit relies on Series - and that I of course > completely agree that Series can't possibly deal with this. Even > worse problems of this type will inevitably happen in the case of > non-real roots, which can switch order in intractable ways. But it > seem to me that in the case of real roots one could use a simple > numeric-symbolic method to get the right answer- which is indeed > what I did by hand before posting this problem. The key point is, > that problem can only occur at a double root, because two conjugate > complex roots must first collide on the real line before a real > root is formed. The double roots can be found by using the > derivative and Resultant, as I did in this case: > > > Reduce[Resultant[poly[b,x], D[poly[b,x]], x] == 0, b, Reals] > > where b is a parameter. Now, if a Limit is taken at a point that is > not a double root continuity can be assumed and we are home. If the > Limit point is a double root, then (in the case of a cubic) we that > the only possibilities for the limit will be the value of the first > or the third real root at this point (where there will be three > real roots). We can use NLimit with significance arithmetic to > settle this. Significance arithmetic is important since the two > branches can be arbitrarily close (we may have a near tripe root). > Actually, we would have to first check algebraically that we do not > have a triple root at this point - if we do, there is no problem > though. > > I can see that doing all this would considerably increase the > complexity of Limit whenever any kind of Root objects were present > in an expression - which may be strong argument against it. On the > other hand, I think these kind of situations are quite interesting > and it would be a good idea to be able to get them right without > having to resort to manual computations, as I did in this case. > Another argument for leaving things as they are, the same kind of > phenomenon for complex roots (and perhaps polynomials of high > degree) seems quite un-manageable so in that sense the problem > would still remain. But I think real roots are interesting and > important, and even if this could be done only for cubic and > quartics, it would be worth while. > If all this is not practical, I think a warning message should > always be issued by Limit whenever such Root objects are > encountered (I think Series already does that). > > > Andrzej Kozlowski > > > > > On 19 Dec 2006, at 01:22, dh wrote: > >> *This message was transferred with a trial version of CommuniGate >> (tm) Pro* >> Hi Andrzej, >> It is definitly a bug. The reason for the bug may be that not only >> the function is not continuous at b == -(3/2^(2/3)), but also the >> numbering changes. There are three different real roots for b<- >> (3/2^(2/3)), therefore, the first is the smallest. For b=-(3/2^ >> (2/3)) the two lowest roots merge and for b>-(3/2^(2/3)) the two >> "former" lowest become complex. And now the first root is the >> "former" highest. MMA seems to keep the number of the root in the >> limit process. To make the bug even worse, the wrong first root at >> b=-(3/2^(2/3)) is a double root and therefore, reduced to a >> quadratic root object. >> Daniel >> >> >> Andrzej Kozlowski wrote: >>> It is easy to check that the function >>> f[b_] := Root[#1^3 + b*#1 - 1 & , 1] >>> is discontinuous at b, where >>> Reduce[Resultant[x^3 + b*x - 1, D[x^3 + b*x - 1, x], x] == 0, b, >>> Reals] >>> b == -(3/2^(2/3)) >>> indeed this was not so long ago discussed in connection with a >>> little argument about "usefulness' of Root objects. In view of >>> this, isn't the following a bug? >>> u = Limit[f[b], b -> -(3/2^(2/3)), Direction -> 1] >>> Root[2*#1^3 + 1 & , 1] >>> v = Limit[Root[#1^3 + b*#1 - 1 & , 1], b -> -(3/2^(2/3)), >>> Direction - > -1] >>> Root[2*#1^3 + 1 & , 1] >>> u == v >>> True >>> It looks like Limit is making life too easy for itself by >>> assuming continuity. >>> Using NLimit shows that things are not as simple: >>> w = NLimit[f[b], b -> -(3/2^(2/3)), Direction -> -1] >>> 1.5874010343874532 >>> z = NLimit[Root[#1^3 + b*#1 - 1 & , 1], b -> -(3/2^(2/3)), >>> Direction - > 1] >>> -0.7937180869283765 >>> Andrzej Kozlowski >> >

**latex label in mathematica graphics**

**Re: Re: image border**

**Re: Limit and Root Objects**

**Re: Limit and Root Objects**