I've been using NSolve a moderate (50-100 equations) size system of linear equations and it has been working splendidly (Solve on the other hand is extremely slow) and I thought I'd look up the method it is using is there anyway to:

a) See which method Mathematica chooses to use for a particular set of equations?

b) See what are the available methods to NSolve. The documentation for NSolve doesn't show anything specific under Details and Options.

  • $\begingroup$ reference.wolfram.com/language/tutorial/… $\endgroup$ Jan 16, 2014 at 11:25
  • 1
    $\begingroup$ _ Polynomial root finding is done based on the Jenkins-Traub algorithm. For sparse linear systems, Solve and NSolve use several efficient numerical methods, mostly based on Gauss factoring with Markowitz products (approximately 250 pages of code). For systems of algebraic equations, NSolve computes a numerical Gröbner basis using an efficient monomial ordering, then uses eigensystem methods to extract numerical roots._ $\endgroup$ Jan 16, 2014 at 11:26
  • $\begingroup$ So if I understand correctly from "Solve and NSolve use several efficient numerical methods, mostly based on Gauss factoring with Markowitz products" - NSolve uses this in all cases concerning linear equations? Still why is NSolve so much quicker than just Solve if the method is essentialy the same. And is there a way to tell Mathematica to explicitly print the method it's using not just for NSolve but other functions where there is a variety of methods to choose from? $\endgroup$ Jan 16, 2014 at 11:30
  • $\begingroup$ Still why is NSolve so much quicker than just Solve numerical methods in general are faster than symbolic, but not as accurate, everything else being equal. $\endgroup$
    – Nasser
    Jan 16, 2014 at 12:46
  • 1
    $\begingroup$ I upvoted it and so far I seem to be the only one to have done so. I know what prevents Mark McClure from upvoting it but not so sure what stops others... $\endgroup$ Dec 29, 2015 at 18:44

2 Answers 2


The basic algorithm might be the same yet the underlying data types are certainly different. Generally, plain old arithmetic with exact rationals is much slower than machine arithmetic with floating point approximations, particularly if the underlying integers grow larger than the largest machine integer on your system, which is 9223372036854775807 on my Mac. Here's an example where the only difference is the starting point, 1 vs 1.0:

Nest[1 + 1/# &, 1, 1000000]; // Timing
Nest[1 + 1/# &, 1.0, 1000000]; // Timing
(* Out:
  {4.714536, Null}

  {0.031917, Null}
  • 2
    $\begingroup$ You are of course right, I tried: Solve[N[equations],variables] and NSolve[equations, variables] and now they work equally quickly. Although I am still wondering how you can ask Mathematica which method it chooses to use if you don't tell it explicitly. $\endgroup$ Jan 16, 2014 at 16:30

To answer part b):

Here are some settings meth for Method -> meth for NSolve:


I found them by searching on the site, and you can find various discussions of them by search for each one. This question, closely related to this one, also seems relevant:

What algorithms does NSolve use?

In addition, options can be passed via the Method option, in the from Method -> {subopt -> value,...}. These may be found this way:

(* V10 result:
  {"ComplexEquationMethod" -> Automatic, "MonomialOrder" -> Automatic, 
   "ReorderVariables" -> True, "SelectCriterion" -> (True &), 
   "Tolerance" -> 0, "UseSlicingHyperplanes" -> True}
  • 1
    $\begingroup$ I believe since V10 "Homotopy" is also a valid method setting. $\endgroup$
    – Greg Hurst
    Jan 21, 2021 at 16:36
  • 1
    $\begingroup$ Thanks, @ChipHurst. Funny I didn't notice the omission, since I just referred to this answer in another one, in which I mentioned "Homotopy". $\endgroup$
    – Michael E2
    Jan 21, 2021 at 16:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.