[Date Index]
[Thread Index]
[Author Index]
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
>
Prev by Date:
**a bug in recursive formula in 64 bit machine**
Next by Date:
**Re: decrementing problem**
Previous by thread:
**Re: Limit and Root Objects**
Next by thread:
**Re: Limit and Root Objects**
| |