Group Abstract

Message Boards

WOLFRAM COMMUNITY

3.2K Views

3 Replies

2 Total Likes

View groups...

Follow this post

Share this post:

GROUPS:

Numerical Computation

NSolve Method -> Automatic Has Problems

Frank Kampas

Frank Kampas, Physicist at Large Consulting

Posted 10 years ago

In the course of doing ellipse packing using Lagrange multipliers, I've discovered that , in some instances, NSolve Method -> Automatic doesn't work whereas setting a variety of Method choices does. The equations defining the problem and all the tests are in the attached notebook. Here are a couple examples: In[6]:= NSolve[ lagceqns[elvals1][elvals2][{x1, y1, \[Lambda]1}][{x2, y2, \[Lambda]2}], {x1, y1, \[Lambda]1, x2, y2, \[Lambda]2}, Reals] Out[6]= {} In[7]:= NSolve[ lagceqns[elvals1][elvals2][{x1, y1, \[Lambda]1}][{x2, y2, \[Lambda]2}], {x1, y1, \[Lambda]1, x2, y2, \[Lambda]2}, Reals, Method -> {"UseSlicingHyperplanes" -> True}] Out[7]= {{x1 -> 2.60915, y1 -> 3.09158, \[Lambda]1 -> -5.49682, x2 -> 0.449195, y2 -> -0.738743, \[Lambda]2 -> 5.80126}, {x1 -> 1.53796, y1 -> 0.834143, \[Lambda]1 -> 5.70837, x2 -> -0.326767, y2 -> -3.32313, \[Lambda]2 -> -6.10992}, {x1 -> 2.41455, y1 -> 3.18634, \[Lambda]1 -> -8.86259, x2 -> -0.288259, y2 -> -3.33973, \[Lambda]2 -> -9.52232}, {x1 -> 1.38751, y1 -> 0.910312, \[Lambda]1 -> 2.37167, x2 -> 0.452039, y2 -> -0.740351, \[Lambda]2 -> 2.50213}} In[8]:= NSolve[ lagceqns[elvals1][elvals2][{x1, y1, \[Lambda]1}][{x2, y2, \[Lambda]2}], {x1, y1, \[Lambda]1, x2, y2, \[Lambda]2}, Reals, Method -> {"UseSlicingHyperplanes" -> False}] Out[8]= {{x1 -> 2.60915, y1 -> 3.09158, \[Lambda]1 -> -5.49682, x2 -> 0.449195, y2 -> -0.738743, \[Lambda]2 -> 5.80126}, {x1 -> 1.53796, y1 -> 0.834143, \[Lambda]1 -> 5.70837, x2 -> -0.326767, y2 -> -3.32313, \[Lambda]2 -> -6.10992}, {x1 -> 2.41455, y1 -> 3.18634, \[Lambda]1 -> -8.86259, x2 -> -0.288259, y2 -> -3.33973, \[Lambda]2 -> -9.52232}, {x1 -> 1.38751, y1 -> 0.910312, \[Lambda]1 -> 2.37167, x2 -> 0.452039, y2 -> -0.740351, \[Lambda]2 -> 2.50213}} In[9]:= NSolve[ lagceqns[elvals1][elvals2][{x1, y1, \[Lambda]1}][{x2, y2, \[Lambda]2}], {x1, y1, \[Lambda]1, x2, y2, \[Lambda]2}, Reals, Method -> {"Homotopy"}] Out[9]= {{x1 -> 2.60915, y1 -> 3.09158, \[Lambda]1 -> -5.49682, x2 -> 0.449195, y2 -> -0.738743, \[Lambda]2 -> 5.80126}, {x1 -> 1.53796, y1 -> 0.834143, \[Lambda]1 -> 5.70837, x2 -> -0.326767, y2 -> -3.32313, \[Lambda]2 -> -6.10992}, {x1 -> 2.41455, y1 -> 3.18634, \[Lambda]1 -> -8.86259, x2 -> -0.288259, y2 -> -3.33973, \[Lambda]2 -> -9.52232}, {x1 -> 1.38751, y1 -> 0.910312, \[Lambda]1 -> 2.37167, x2 -> 0.452039, y2 -> -0.740351, \[Lambda]2 -> 2.50213}} Attachments:

In the course of doing ellipse packing using Lagrange multipliers, I've discovered that , in some instances, NSolve Method -> Automatic doesn't work whereas setting a variety of Method choices does. The equations defining the problem and all the tests are in the attached notebook. Here are a couple examples:

In[6]:=  NSolve[
 lagceqns[elvals1][elvals2][{x1, y1, \[Lambda]1}][{x2, 
   y2, \[Lambda]2}], {x1, y1, \[Lambda]1, x2, y2, \[Lambda]2}, Reals]

Out[6]= {}

In[7]:=  NSolve[
 lagceqns[elvals1][elvals2][{x1, y1, \[Lambda]1}][{x2, 
   y2, \[Lambda]2}], {x1, y1, \[Lambda]1, x2, y2, \[Lambda]2}, Reals, 
 Method -> {"UseSlicingHyperplanes" -> True}]

Out[7]= {{x1 -> 2.60915, y1 -> 3.09158, \[Lambda]1 -> -5.49682, 
  x2 -> 0.449195, 
  y2 -> -0.738743, \[Lambda]2 -> 5.80126}, {x1 -> 1.53796, 
  y1 -> 0.834143, \[Lambda]1 -> 5.70837, x2 -> -0.326767, 
  y2 -> -3.32313, \[Lambda]2 -> -6.10992}, {x1 -> 2.41455, 
  y1 -> 3.18634, \[Lambda]1 -> -8.86259, x2 -> -0.288259, 
  y2 -> -3.33973, \[Lambda]2 -> -9.52232}, {x1 -> 1.38751, 
  y1 -> 0.910312, \[Lambda]1 -> 2.37167, x2 -> 0.452039, 
  y2 -> -0.740351, \[Lambda]2 -> 2.50213}}

In[8]:=  NSolve[
 lagceqns[elvals1][elvals2][{x1, y1, \[Lambda]1}][{x2, 
   y2, \[Lambda]2}], {x1, y1, \[Lambda]1, x2, y2, \[Lambda]2}, Reals, 
 Method -> {"UseSlicingHyperplanes" -> False}]

Out[8]= {{x1 -> 2.60915, y1 -> 3.09158, \[Lambda]1 -> -5.49682, 
  x2 -> 0.449195, 
  y2 -> -0.738743, \[Lambda]2 -> 5.80126}, {x1 -> 1.53796, 
  y1 -> 0.834143, \[Lambda]1 -> 5.70837, x2 -> -0.326767, 
  y2 -> -3.32313, \[Lambda]2 -> -6.10992}, {x1 -> 2.41455, 
  y1 -> 3.18634, \[Lambda]1 -> -8.86259, x2 -> -0.288259, 
  y2 -> -3.33973, \[Lambda]2 -> -9.52232}, {x1 -> 1.38751, 
  y1 -> 0.910312, \[Lambda]1 -> 2.37167, x2 -> 0.452039, 
  y2 -> -0.740351, \[Lambda]2 -> 2.50213}}

In[9]:=  NSolve[
 lagceqns[elvals1][elvals2][{x1, y1, \[Lambda]1}][{x2, 
   y2, \[Lambda]2}], {x1, y1, \[Lambda]1, x2, y2, \[Lambda]2}, Reals, 
 Method -> {"Homotopy"}]

Out[9]= {{x1 -> 2.60915, y1 -> 3.09158, \[Lambda]1 -> -5.49682, 
  x2 -> 0.449195, 
  y2 -> -0.738743, \[Lambda]2 -> 5.80126}, {x1 -> 1.53796, 
  y1 -> 0.834143, \[Lambda]1 -> 5.70837, x2 -> -0.326767, 
  y2 -> -3.32313, \[Lambda]2 -> -6.10992}, {x1 -> 2.41455, 
  y1 -> 3.18634, \[Lambda]1 -> -8.86259, x2 -> -0.288259, 
  y2 -> -3.33973, \[Lambda]2 -> -9.52232}, {x1 -> 1.38751, 
  y1 -> 0.910312, \[Lambda]1 -> 2.37167, x2 -> 0.452039, 
  y2 -> -0.740351, \[Lambda]2 -> 2.50213}}

POSTED BY: Frank Kampas

3 Replies

Sort By:

Frank Kampas

Frank Kampas, Physicist at Large Consulting

Posted 10 years ago

I was puzzled by the fact that "UseSlicingHyperplanes" -> True or False both worked, but not specifying it didn't.

POSTED BY: Frank Kampas

Daniel Lichtblau

Daniel Lichtblau, Wolfram Research

Posted 10 years ago

The reason is fairly mundane. Specifying any nonautomatic method besides "Homotopy" will have the effect of pushing `NSolve either into the endomorphism matrix code or, possibly, into just rationalizing coefficients and invoking`Solve`. Even`Method->{"Homotopy"}`(with the curly braces) will cause it to avoid the`Method-> "Homotopy"` internals. I only just now learned we have documented the alternative `Method-> "EndomorphismMatrix"`. Maybe we will at some point remove this seemingly weird behavior of having `Method->whateverIWriteHere` interpreted as `Method-> "EndomorphismMatrix"`. (This wasn't so weird back when we had not documented `Method-> "EndomorphismMatrix"`. That in turn took time because we had not settled on a name. I like the choice we opted for. Unfortunately though, as recently as yesterday I used `Method-> "CompanionMatrix"` on Mathematica.StackExchance.com. Wish I had known about the more recent documentation of `"EndomorphismMatrix"`.)

POSTED BY: Daniel Lichtblau

Daniel Lichtblau

Daniel Lichtblau, Wolfram Research

Posted 10 years ago

I'm going to file a bug report about this although I suspect it is already known. The synopsis is this. In version 10 a new default method was introduced for `NSolve` with systems of polynomials. It is typically faster for large systems but on the down side it has more issues in terms of assessing convergence and, related, assessing that imaginary parts are zero. In this case it you remove the `Reals` domain specification you get solutions with relatively small imaginary parts (by "relatively" I mean in comparison to the respective real parts). For concreteness, a look at the `x1` values from the two methods of solving might be illuminating. In[7]:= sys = lagceqns[elvals1][elvals2][{x1, y1, [Lambda]1}][{x2, y2, [Lambda]2}]; In[12]:= Timing[ sol1 = NSolve[sys, {x1, y1, [Lambda]1, x2, y2, [Lambda]2}];] Out[12]= {0.739963, Null} In[11]:= Timing[ sol2 = NSolve[sys, {x1, y1, [Lambda]1, x2, y2, [Lambda]2}, Method -> "EndomorphismMatrix"];] Out[11]= {0.110485, Null} In[15]:= Sort[x1 /. sol1] Out[15]= {-13.5451383942 + 21.8103241909 I, -13.5442231547 - 21.8292191276 I, -0.572877955342 - 0.136894164084 I, -0.57249589672 + 0.136841062303 I, 0.870768072729 + 1.77912568313 I, 0.870950055142 - 1.77900031602 I, 1.38744232427 - 0.0000499914442125 I, 1.53791492145 - 0.0000544433486066 I, 2.41472608101 - 0.00012162315463 I, 2.60928049269 - 0.000046672566395 I, 4.55037173442 + 0.152913287369 I, 4.55061555521 - 0.151741365885 I, 5.69265655088 - 11.1523901476 I, 5.69279664832 + 11.1538655562 I, 10.020880237 - 9.02896317173 I, 10.0243837113 + 9.03159186327 I} In[17]:= Sort[x1 /. sol2] Out[17]= {-13.5471062209 - 21.8053897352 I, -13.5471062209 + 21.8053897352 I, -0.572557265734 - 0.136913931222 I, -0.572557265734 + 0.136913931222 I, 0.870812111804 - 1.77909711673 I, 0.870812111804 + 1.77909711673 I, 1.38750965045, 1.53795502702, 2.41455007976, \ 2.60914871541, 4.54978943808 - 0.152101865593 I, 4.54978943808 + 0.152101865593 I, 5.69224798593 - 11.1520276461 I, 5.69224798593 + 11.1520276461 I, 10.0205016075 - 9.02895061192 I, 10.0205016075 + 9.02895061192 I} One sees that four roots claimed to be real in the second result instead have imaginary parts around 5-6 orders of magnitude smaller than corresponding real parts in the first result.

POSTED BY: Daniel Lichtblau

Reply to this discussion

Reply Preview

Attachments

Remove Add a file to this post

Follow this discussion

or Discard

Feedback