MathGroup Archive 2010

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

Search the Archive

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


  • Prev by Date: Re: Re-virginating Manipulates?
  • Next by Date: Re: Extract[expr, Position[expr, patt], h]
  • Previous by thread: Re: Problems with Mathematica 8.0 Solve
  • Next by thread: Re: Problems with Mathematica 8.0 Solve