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