Re: Problems with Mathematica 8.0 Solve
- To: mathgroup at smc.vnet.net
- Subject: [mg114280] Re: Problems with Mathematica 8.0 Solve
- From: Daniel Lichtblau <danl at wolfram.com>
- Date: Tue, 30 Nov 2010 04:01:32 -0500 (EST)
leigh pascoe wrote:
> [...]
>
> Dear Daniel,
>
> Thanks for your most helpful suggestions. It is good to know that the
> legacy option is available for "symbolic" solution of the equations when
> needed.
>
> When writing about the method I have used to analyse my data, I can
> write equations relating the parameters to be estimated {x,y} and the
> observed data {a,b..,g}. Obviously in that case one would like to have
> simple symbolic solutions, x=f(a,b..)etc. However in the present case
> that seems impossible, as the symbolic solutions take up several pages
> and give little insight. In any case no editor would permit publication
> of the formulas for want of space.
The approach indicates below will make them smaller, but still perhaps
too large/ugly for publication.
> To get numerical values for the parameters in a particular experiment
> it is easy to substitute the observed data into the formulas to estimate
> the parameters, in Ma 7.0.
>
> In Mathematica 8.0 the solution of the equations seems impossible
> (without invoking the legacy method), despite the fact that they appear
> relatively simple. However numerical results can be obtained as
> suggested in your email in two ways:
>
> 1. By substituting the data values into the equations first and then
> solving them. The command you suggested doesn't in fact solve the
> equations, I presume because of a misplacement of parentheses viz
>
> Timing[solns = Map[Solve[(exprs /. #) == 0, Cubics -> False] &,
> Take[subs, 4]];]
>
> However it prompted me to find the syntax that did
>
> sols = N[Map[Solve[expr /. #, Cubics -> False] &, subs2]]
I suspect the difference is that I changed your equations to
expressions, that is, removed the '==0' parts. Hence the different behavior.
> 2. The solutions can also be found using Nsolve directly as you suggested
>
> sols2 = Map[NSolve[expr /. #] &, subs2]
>
> In summary it turns out to be more efficient to solve the equations
> multiple times with specific coefficients than to solve them generally
> and evaluate the particular solutions.
Yes.
> The above commands solve my immediate problem but not my curiousity.
> Could anyone comment on the methods used by 7.0 and 8.0 to solve systems
> of equations?
I've not looked to hard to figure out why it ever worked. "Dumb luck" is
most likely the right answer. I am fairly sure it has to do with the
older Solve using a really rickety Groebner basis code internally. This
code in effect treats all parameters as "variables", and creates a slew
of new polynomials. It then has the good luck to be able to formulate
symbolic roots in one variable, winding its way backwards through these
polynomial equations until it can also provide roots for the second one.
That it does not choke on the sizes is a strike of luck, I suspect.
Version 8 Solve attempts to compute a lexicographic Groebner basis over
a field of fractions in the parameters. I gather this turns out to be
very difficult for this example, and it hangs here. I do not know
offhand whether this indicates a limitation of our Groebnerbasis code,
or this is just an intrinsically difficult computation.
> Why is it easier to solve the equations with exact
> numerical coefficients than with symbolic constants?
The Groebner basis computations can be much more strenuous, and the
results much larger, when there are symbolic parameters in the mix.
> Would it be easier
> if the data values were limited to positive integers?
I doubt it.
> Is Reduce a
> preferred command in this situation?
It could be, if inequality or domain information were useful. Though I
think version 8 Solve might also avail itself of such information.
The problem is that such information might not make the algorithmic
complexity improve. It might even get worse. (Why? Because it might
force use of cylindrical algebraic decomposition, and that in turn might
be more strenuous even than the GroebnerBasis computation it is already
doing).
The above are just general observations. Only experimentation will show
whether or not such assumptions do help for your particular computation.
> I can't get much assistance from
> the Help files on these questions.
>
> Thanks again
>
> LP
Here is another workaround, if you really want a parametrized solution
set (already sent your way in private email).
exprs = Together[{(b + d + f)/x - (a + b)/(1 + x) -
2*(c + d + e)/(1 + 2*x + y) - (f + g)/(x + y),
(e + g)/y - (c + d + e)/(1 + 2*x + y) - (f + g)/(x + y)}];
Use NSolve, but at infinite precision. In this case it will not mind
that there are symbolic parameters, that is, non-numeric input.
In[2]:= Timing[solns = NSolve[exprs, {x,y},
WorkingPrecision->Infinity];]
Out[2]= {29.5225, Null}
Compare to legacy (versions <=7) Solve.
In[3]:= Timing[solns2 = Solve[exprs == 0, {x, y}, Method->"Legacy"];]
Out[3]= {22.6456, Null}
In[4]:= LeafCount[solns]
Out[4]= 37318
In[5]:= LeafCount[solns2]
Out[5]= 232642
Daniel Lichtblau
Wolfram Research