EDIT: I filed a bug report and after a small back-and-forth the support person agreed this is a bug. He said: "I have filed a report with the developers to issue warning messages when the arithmetic can affect the results." I'm satisfied with that.

I noticed an odd mismatch between the behaviors of NDSolve and FindRoot.

If you give NDSolve an equation of a certain precision, say 20, and tell it to use a higher WorkingPrecision, say 30, it will complain (and rightly so), since it can't maintain a precision greater than it started with. For example:

NDSolve[{y'[x] == 2.0``20, y[0] == 0}, {y}, {x, 0, 1}, WorkingPrecision -> 30];

NDSolve::precw: The precision of the differential equation ({{(y^\[Prime])[x]==2.0000000000000000000,y[0]==0},{},{},{},{}})
is less than WorkingPrecision (30.`). >>

However, FindRoot seems to be more forgiving than it should be in a similar situation. For instance, if you have a function y[x] = 2x to precision 20...

sol = NDSolve[{y'[x] == 2.0``21, y[0] == 0}, {y}, {x, 0, 1}, WorkingPrecision -> 21];
y[x_] = Evaluate[y[x] /. sol[[1]]];


...and you use it in FindRoot with WorkingPrecision->30...

root = FindRoot[y[x] == 1.0``30, {x, 0.4``20}, WorkingPrecision -> 30]

{x -> 0.500000000000000000000000000000}

...it doesn't complain at all! It even claims that it's able to keep a full precision of 30:



Which is seemingly does, despite having an equation less precise than that. It does complain if both sides of the given equation don't have high enough precision:

root = FindRoot[y[x] == 1.0``20, {x, 0.4``20}, WorkingPrecision -> 30]

FindRoot::precw: The precision of the argument function (InterpolatingFunction[{{0,1.00000000000000000000}},{5,3,1,{16},{4},0,0,0,0,Automatic,{},{},False},{{0,<<14>>,1.00000000000000000000}},{{0,2.00000000000000000000},{5.02973371873174322338*10^-6,2.00000000000000000000},<<12>>,{1.87545103551469488009,2.00000000000000000000},{2.00000000000000000000,2.00000000000000000000}},{Automatic}][x]==1.0000000000000000000)
is less than WorkingPrecision (30.`). >>

but I can't see why it would have a problem with the latter case but not the former.

  • $\begingroup$ My assumption would be FindRoot makes its assessment based on the expression you supply before it begins evaluation. It doesn't know the precision of y[x] until after it supplies a numeric argument. $\endgroup$
    – george2079
    Commented Jul 23, 2015 at 21:24
  • $\begingroup$ I'm inclined to agree, but this (a) seems problematic and (b) doesn't explain why the answer would claim to have precision equal to WorkingPrecision. $\endgroup$
    – Max
    Commented Jul 23, 2015 at 23:21

2 Answers 2


Based on a discussion with the developers, FindRoot does not take into account the precision of heads when issuing the message, because it isn't necessarily related to the actual function values.

For an example,

x[1.][z_?NumberQ] := z^2 - 2

FindRoot[x[1.][z] == 0, {z, 2}, WorkingPrecision -> 20]

(* {z -> 1.4142135623730950488} *)

should not issue any warning, despite x[1.] having only machine precision. Since x[1.][z] only evaluates for numeric z, the objective function is simply a black-box to FindRoot.

Also, one should be careful in the interpretation of the Precision of a result, which is just a property of the number itself.

It is determined by the precision of the input numbers and the arithmetic operations done with them, but does not necessarily say much about how accurate the result might be in terms of convergence to an exact solution.

I would also take this opportunity to recommend reading the answer to the Is manual adjustment of AccuracyGoal and PrecisionGoal useless? question.


For FindRoot the precision of the initial guess does not matter. The initial guess need not satisfy anything, since it will be updated. It is the equation that must be satisfied by a solution, and it is the equation that should have a sufficient precision (that is, at least WorkingPrecision). Whatever the precision of the initial guess, there is no problem in changing its precision to the WorkingPrecision. The adjustment in precision could be considered a preliminary step or update to the initial guess.

For NDSolve, it is the whole system that must be satisfied: the ODEs and the BCs/ICs. Thus the whole system should have a sufficient precision, at least that of WorkingPrecision.

Finally, both commands issue a warning when the appropriate equations have insufficient precision, but they promote the precision of the equations to WorkingPrecision nonetheless. The warning just points out that the user is asking for something that does not make sense on the face of it: The insufficient precision might be due to a user mistake, or, in the case of a computed equation, to too great a loss of precision in computing the equation.

  • $\begingroup$ But FindRoot doesn't issue a warning when the function y[x] is insufficient precision. If I understand your answer, you're saying "that's just how FindRoot works", which doesn't seem to answer my problem. My problem is that FindRoot deceives me where it should warn me. I accidentally feed it a function y[x] of insufficient precision, and it glazes over that issue and tells me it found me a very precise answer. That's just mathematically incorrect. Is there a reason I'm not seeing for why the precision of a function y[x] shouldn't be inherited by its argument x during FindRoot? $\endgroup$
    – Max
    Commented Jan 31, 2018 at 5:53
  • $\begingroup$ @Max Ah, I think I didn't realize it was the same y[x] throughout the post. I never do things like y[x_] = Evaluate[y[x] /. sol[[1]]] because it destroys y (you can't use y[x] or the original ODE as symbolic expressions). I overlooked its importance to your question. -- Yes InterpolatingFunction seems to be mishandled. Will delete. $\endgroup$
    – Michael E2
    Commented Jan 31, 2018 at 11:31
  • 1
    $\begingroup$ Fair point about my lazy handling of y[x]. If there's a way you think I can clarify that in the question I could edit it. You could also keep your answer and add a note to help others avoid the confusion in the future. $\endgroup$
    – Max
    Commented Feb 1, 2018 at 0:59

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.