Re: Re: problem solving polynomial equations
- To: mathgroup at smc.vnet.net
- Subject: [mg61452] Re: [mg61342] Re: [mg61306] problem solving polynomial equations
- From: Daniel Lichtblau <danl at wolfram.com>
- Date: Wed, 19 Oct 2005 02:17:01 -0400 (EDT)
- References: <200510140953.FAA28482@smc.vnet.net> <200510150222.WAA17287@smc.vnet.net> <200510160417.AAA22567@smc.vnet.net>
- Sender: owner-wri-mathgroup at wolfram.com
Andrzej Kozlowski wrote:
> On 15 Oct 2005, at 11:22, wtplasar at ehu.es wrote:
>
>
>>Hi,
>>
>>
>>I have two equations. The first one is
>> [...]
>
> Basically what happens is this. Solve can't find the general solution
> to parametric equations of this kind. (It is not the fault of Solve;
> there is really no way to do it). So what it does is returns
> basically any solutions it can find, by using certain "heuristic"
> methods. One method is simply to set some variables to 0 and see if
> the equations can be solved for the remaining ones. This is what
> seems to happen here:
>
>
> Solve[{eqy == 0, eqz == 0}, {y, z}] /. Sign[s]^2 -> 1
>
>
> {{y -> (1/4)*((-r)*Sign[s] - Sqrt[r^2 - 8*b]), z -> 0},
> {y -> (1/4)*(r*Sign[s] - Sqrt[r^2 - 8*b]), z -> 0},
> {y -> (1/4)*(Sqrt[r^2 - 8*b] - r*Sign[s]), z -> 0},
> {y -> (1/4)*(r*Sign[s] + Sqrt[r^2 - 8*b]), z -> 0},
> {y -> 0}}
>
> These are the kind of solutions you could find yourself by hand!
>
> Now for the other case.
>
> Solve[{Numerator[eqy] == 0, Numerator[eqz] == 0}, {y, z}] /. Sign[s]
> ^2 -> 1
>
> This is pure speculation, but I would guess Solve has for some reason
> started to apply some algorithm that might give additional solutions.
> Unfortunately there is no reason to believe that the computation will
> finish in reasonable time. This could in fact be one of the cases
> where "better is worse", meaning that the fact that the equations are
> "better" (so Mathematica makes a serious attempt to find solutions)
> cases no solutions to be returned. To see this phenomenon in an
> extreme form on a trivial example, compare these two equations:
>
>
>
> Solve[x (Exp[Sin[x]-Cos[x]])\[Equal]0,x]
>
> Inverse functions are
> being used
> by Solve, so some solutions may not be \
> found; use Reduce for complete solution information.
>
> {{x->0}}
>
> Solve can do nothing with this except find the trivial solution so it
> quickly returns the trivial solution. Now consider the following
> equation that I made up at random:
>
> Solve[(x^32 - x^31)^(1/12) + (x^7 - x^11/3)^(1/5) + 17x + 5 == 0, x]
>
> This is "better" than the other one, since Mathematica, in principle
> knows algorithms for solving equations of this type. But it is
> "worse" since the computation is unlikely to finish (I did not wait
> long but even if this ever finishes one can produce a more
> complicated example that will not).
>
> So, I think what happened in your case is that your second set of
> equations is sufficiently "better" than the first to make it actually
> "worse".
>
> Well, of course, this is only speculation. Daniel Lichtblau can
> almost certainly tell if it is true, if he chooses to.
>
> Andrzej Kozlowski
>
The general principle that a more "transcendental" system might be
solved faster than an "algebraic" one is correct. Moreover various
tweaks in Solve over the years have had the effect of changing from one
category to the other e.g. in handling of trigonometric systems.
For the system in question (replicated below) everything is algebraic,
so this particular aspect of the issue is not involved. But then one can
have seemingly similar systems with different levels of algebraic
complexity, and that is what happens in these examples.
eqy = (y*(3*b^2 + 12*b*y^2 + 12*y^4 + 3*b^2*z^4 + 4*b*y^2*z^4 +
3*r*y*Sqrt[4*y^4 + 4*b*y^2*(1 + z^4) + b^2*(1 + 3*z^4) +
z^2*(8*b*y^2 + 4*y^4 + b^2*(3 + z^4))*Sign[k]]*Sign[s] +
z^2*Sign[k]*(6*b^2 + 16*b*y^2 + 8*y^4 +
r*y*Sqrt[4*y^4 + 4*b*y^2*(1 + z^4) + b^2*(1 + 3*z^4) +
z^2*(8*b*y^2 + 4*y^4 + b^2*(3 + z^4))*Sign[k]]*Sign[s])))/
(3*(3*b^2 + 8*b*y^2 + 4*y^4 + 3*b^2*z^4 +
2*b*(3*b + 4*y^2)*z^2*Sign[k] +
2*r*y*Sqrt[4*y^4 + 4*b*y^2*(1 + z^4) + b^2*(1 + 3*z^4) +
z^2*(8*b*y^2 + 4*y^4 + b^2*(3 + z^4))*Sign[k]]*Sign[s]));
eqz = (y*z*(4*b*y + 8*y^3 + 4*b*y*z^4 +
r*Sqrt[4*y^4 + 4*b*y^2*(1 + z^4) + b^2*(1 + 3*z^4) +
z^2*(8*b*y^2 + 4*y^4 + b^2*(3 + z^4))*Sign[k]]*Sign[s] +
z^2*Sign[k]*(8*b*y + 8*y^3 + r*Sqrt[4*y^4 + 4*b*y^2*(1 + z^4) +
b^2*(1 + 3*z^4) + z^2*(8*b*y^2 + 4*y^4 +
b^2*(3 + z^4))*Sign[k]]*
Sign[s])))/(3*(3*b^2 + 8*b*y^2 + 4*y^4 + 3*b^2*z^4 +
2*b*(3*b + 4*y^2)*z^2*Sign[k] +
2*r*y*Sqrt[4*y^4 + 4*b*y^2*(1 + z^4) + b^2*(1 + 3*z^4) +
z^2*(8*b*y^2 + 4*y^4 + b^2*(3 + z^4))*Sign[k]]*Sign[s]));
Just to be safe we'll force expressions into form numerator/denominator
(I think they are that way already, but no reason not to be certain).
{eqy2,eqz2} = Together[{eqy,eqz}];
We've seen that we can do
ss1 = Solve[{eqy2,eqz2}==0, {y, z}]
but not
eenum = Numerator[{eqy2,eqz2}];
ssnum = Solve[eenum==0, {y,z}]
Why not? I checked in a debugger and found that the following
intermediate systems were spawned. I'll set these up with assignments so
it can be seen as a "standalone" system.
e1 = 4*b*y + 8*y^3 + 4*b*y*z^4 + 8*b*y*z^2*Sign[k] + 8*y^3*z^2*Sign[k] +
r*Sqrt[b^2 + 4*b*y^2 + 4*y^4 + 3*b^2*z^4 + 4*b*y^2*z^4 +
3*b^2*z^2*Sign[k] + 8*b*y^2*z^2*Sign[k] + 4*y^4*z^2*Sign[k] +
b^2*z^6*Sign[k]]*Sign[s] + r*z^2*Sign[k]*
Sqrt[b^2 + 4*b*y^2 + 4*y^4 + 3*b^2*z^4 + 4*b*y^2*z^4 +
3*b^2*z^2*Sign[k] + 8*b*y^2*z^2*Sign[k] + 4*y^4*z^2*Sign[k] +
b^2*z^6*Sign[k]]*Sign[s] == 0 &&
3*b^2 + 12*b*y^2 + 12*y^4 + 3*b^2*z^4 + 4*b*y^2*z^4 +
6*b^2*z^2*Sign[k] +
16*b*y^2*z^2*Sign[k] + 8*y^4*z^2*Sign[k] +
3*r*y*Sqrt[b^2 + 4*b*y^2 + 4*y^4 + 3*b^2*z^4 + 4*b*y^2*z^4 +
3*b^2*z^2*Sign[k] + 8*b*y^2*z^2*Sign[k] + 4*y^4*z^2*Sign[k] +
b^2*z^6*Sign[k]]*Sign[s] + r*y*z^2*Sign[k]*
Sqrt[b^2 + 4*b*y^2 + 4*y^4 + 3*b^2*z^4 + 4*b*y^2*z^4 +
3*b^2*z^2*Sign[k] + 8*b*y^2*z^2*Sign[k] + 4*y^4*z^2*Sign[k] +
b^2*z^6*Sign[k]]*Sign[s] == 0;
e2 = 3*b^2 + 8*b*y^2 + 4*y^4 + 3*b^2*z^4 + 6*b^2*z^2*Sign[k] +
8*b*y^2*z^2*Sign[k] + 2*r*y*Sqrt[b^2 + 4*b*y^2 + 4*y^4 + 3*b^2*z^4 +
4*b*y^2*z^4 + 3*b^2*z^2*Sign[k] + 8*b*y^2*z^2*Sign[k] +
4*y^4*z^2*Sign[k] + b^2*z^6*Sign[k]]*Sign[s] != 0;
Note that these are both algebraic (though not polynomial) in the
variables {y,z}. The first above, e1, is a subsystem spawned from the
numerators only. When we include denominators we also have the
unequation given as e2. The system that does not hang is in essence the
first one below.
In[40]:= Timing[ss2 = Solve[e1 && e2, {y,z}]]
Out[40]= {0.043993 Second, {}}
We see that there is not solution; presumably the denominator unequation
conflicts with one of the numerator-induced equations.
Without the denominator unequation it turns out that Solve must work
much harder:
In[42]:= Timing[ss1 = Solve[e1, {y,z}]]
(Has not finished after several minutes.)
Conclusion: Algebraic complexity bogs down the seemingly simpler
numerator-only system, but not the original system.
Daniel Lichtblau
Wolfram Research
- References:
- Re: Solving Diophantine Equations
- From: Andrzej Kozlowski <andrzej@yhc.att.ne.jp>
- problem solving polynomial equations
- From: wtplasar@ehu.es
- Re: problem solving polynomial equations
- From: Andrzej Kozlowski <akoz@mimuw.edu.pl>
- Re: Solving Diophantine Equations