Re: Limit and Root Objects

*To*: mathgroup at smc.vnet.net*Subject*: [mg72305] Re: Limit and Root Objects*From*: Andrzej Kozlowski <andrzej at akikoz.net>*Date*: Tue, 26 Dec 2006 04:38:05 -0500 (EST)*References*: <em606c$2o1$1@smc.vnet.net> <4586C045.2020805@metrohm.ch>

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 >

**a bug in recursive formula in 64 bit machine**

**Re: decrementing problem**

**Re: Limit and Root Objects**

**Re: Limit and Root Objects**