Services & Resources / Wolfram Forums
-----
 /
MathGroup Archive
2006
*January
*February
*March
*April
*May
*June
*July
*August
*September
*October
*November
*December
*Archive Index
*Ask about this page
*Print this page
*Give us feedback
*Sign up for the Wolfram Insider

MathGroup Archive 2006

[Date Index] [Thread Index] [Author Index]

Search the Archive

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


  • Prev by Date: latex label in mathematica graphics
  • Next by Date: Re: Re: image border
  • Previous by thread: Re: Limit and Root Objects
  • Next by thread: Re: Limit and Root Objects