2

I know that Mathematica has great built-in precision tracking, so when you do calculations with arbitrary-precision numbers, Mathematica keeps track of the precision on the result. Given this careful attention to numerical error and precision tracking, I am surprised that, say

InputForm[NIntegrate[E^(-x^2), {x, 0, Infinity},PrecisionGoal -> 20, WorkingPrecision -> 100]]

returns a number with precision 100, not 20. I know Mathematica is using precision-100 numbers in its numerical calculations for NIntegrate, but the function is built to return a number whose actual precision is at least 20. In the spirit of useful precision tracking, wouldn't it make more sense for NIntegrate to return a number with a precision of PrecisionGoal, not WorkingPrecision?

This question is more about numerical coding philosophy than about how NIntegrate works. But this is important as Wolfram presumably makes these decisions with use cases in mind, so I want to know if I'm missing something.

EDIT:

To add context, I've started manually setting the precision of my NIntegrate results to PrecisionGoal, and I want to know if/why this would be a bad idea. It seems perfectly logical to me, but it concerns me that this isn't already the default behavior.

WillG
  • 960
  • 4
  • 14
  • 2
    The purpose and interpretation of PrecisionGoal are pretty well defined in its function page. So, I think it is a clear "no". (But I am very biased. Also, the word "precision" as technical term is overloaded, so I can see how questions similar to the posted one can arise...) – Anton Antonov Jan 28 '21 at 01:04
  • 3
    Interesting topic although a bit out of scope for MSE. I didn't design this but I do believe the current behavior is appropriate whereas returning at the PrecisionGoal would be a bad idea. For one, it might not be reached. Then, as @AntonAntonov notes, it need not mean quite what you expect. In a solver it could, say, involve relative error of a residual. Would it be a good design to have different output precision conventions for NIntegrate vs NSolve? I could probably come up with more objections but these are what first came to mind. – Daniel Lichtblau Jan 28 '21 at 14:48
  • @AntonAntonov I don't see what information on the function page supports your "no". In fact, it claims PrecisionGoal "specifies how many effective digits of precision should be sought in the final result." And the function page for Precision claims that it "gives the effective number of digits of precision in the number x." This reads to me as if PrecisionGoal is the right thing to use as the Precision of the final result. – WillG Jan 28 '21 at 17:13
  • @DanielLichtblau Re: "it might not be reached": Since PrecisionGoal < WorkingPrecision, one could argue that PrecisionGoal is still the better option since it overestimates the true precision by less, in these cases. As for your 2nd objection, I would say NSolve should also use PrecisionGoal for the precision of its output, by the same logic. – WillG Jan 28 '21 at 17:15
  • 3
    It is not easy to support a PrecisionGoal in NSolve. (First question: what does it mean? Second question: Once you have answered the first, how do you then attain it?) I think know the answers at least for the case of polynomial systems. Again, not easy. – Daniel Lichtblau Jan 28 '21 at 17:30
  • @DanielLichtblau Fair questions—I thought it was already an option for NSolve. I don't know how this function works, or what the answers to your questions should be. But PrecisionGoal is an option for FindRoot, so there must exist answers to your questions for FindRoot. Perhaps NSolve should be similar? – WillG Jan 28 '21 at 17:37
  • 2
    With FindRoot the meaning is probably not what you would expect. If I remember correctly, the XXXGoal options are gauged by residuals (relative to root for precision, absolute residual for accuracy). This is not the same as counting correct digits of the result. – Daniel Lichtblau Jan 28 '21 at 17:53
  • I'm sure there are subtleties to these things that I don't understand. But for what it's worth, the description given by Wolfram on the FindRoot function page is: "The setting for PrecisionGoal specifies the number of digits of precision to seek in the value of the position of the root." – WillG Jan 28 '21 at 18:00
  • 2
    There is some discussion of PrecisionGoal and AccuracyGoal here: https://mathematica.stackexchange.com/questions/118249/is-manual-adjustment-of-accuracygoal-and-precisiongoal-useless/139311#139311 -- They have different meanings in FindRoot and NIntegrate. – Michael E2 Jan 29 '21 at 03:31

1 Answers1

5

After going to all the trouble of calculating a 100-digit result, which happens to be accurate to 33 digits in the OP's example,* as a user I would be upset if NIntegrate threw away the extra digits of precision that it had spent the time to find. A user can throw them away if they want to, with SetPrecision[] or N[]. Once the digits are thrown away, the user cannot recover the lost digits. These three things, getting the most accurate answer, the user can then reduce the accuracy at well, and not being able to get back the more accurate answer if the less accurate is returned, are the principal reasons I think the current design is better.

A secondary reason is my understanding of what "working precision" means. It is the precision in which the calculations are to be carried out. The design is that the input should be at least the working precision and the output should be the working precision. Numerically it makes sense to carry out computations at a higher working precision than the desired precision of the result. If NIntegrate is a step in a sequence of computations, it makes sense to keep the computations at the user-requested WorkingPrecision.

*The error estimate in NIntegrate tends to be larger than the actual error when the integrand is well-behaved (e.g. analytic over the interval of integration or, as in this case, non-oscillatory and rapidly decreasing). When NIntegrate stops in such a case, the result is usually more precise than the PrecisionGoal by several digits.

Michael E2
  • 235,386
  • 17
  • 334
  • 747
  • (1) This is not a great answer. – Daniel Lichtblau Jan 29 '21 at 14:34
  • (2) But it is a good answer, and I upvoted. – Daniel Lichtblau Jan 29 '21 at 14:34
  • 1
    (3) The one you linked to in a comment under the original post, now that was a truly great answer. – Daniel Lichtblau Jan 29 '21 at 14:35
  • @DanielLichtblau Thanks, I guess. :) The other question had better focus, perhaps. It was certainly more clearly focused on numerical mathematics. Here I read the question as asking for opinions on the design of WorkingPrecision. Maybe the OP has in mind the way N[expr, p] works, in which N adapts the working precision until the precision goal (or internal limits) is reached, and, if successful, returns a number with the requested precision. (I don't know how N works internally, so "working precision" may not be an accurate term.) – Michael E2 Jan 29 '21 at 15:00
  • 1
    There is no way to give a "great" answer here, and yours was quite good so I guess that's about the best one can do. Just having some fun on a Friday morning before starting my day job. And I'd have upvoted the great answer, except I already did that a few years ago. – Daniel Lichtblau Jan 29 '21 at 15:14
  • The two points brought up here make decent enough sense to me. I was mainly just trying to understand WorkingPrecision might possibly be used over PrecisionGoal, since for my purposes the latter seems much more appropriate. – WillG Jan 29 '21 at 20:07
  • I'll probably end up accepting this answer, just want to wait a few days in case other people who look at it continue to have things to add. – WillG Jan 29 '21 at 20:12
  • 1
    @WillG Succinctly, if you know the distinction: Raising WorkingPrecision lowers round-off error. Raising PrecisionGoal lowers truncation error (up to the limits of WorkingPrecision). – Michael E2 Jan 29 '21 at 23:21