2
$\begingroup$

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.

$\endgroup$
9
  • 2
    $\begingroup$ 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...) $\endgroup$ Jan 28 at 1:04
  • 3
    $\begingroup$ 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. $\endgroup$ Jan 28 at 14:48
  • 3
    $\begingroup$ 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. $\endgroup$ Jan 28 at 17:30
  • 2
    $\begingroup$ 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. $\endgroup$ Jan 28 at 17:53
  • 2
    $\begingroup$ There is some discussion of PrecisionGoal and AccuracyGoal here: mathematica.stackexchange.com/questions/118249/… -- They have different meanings in FindRoot and NIntegrate. $\endgroup$
    – Michael E2
    Jan 29 at 3:31
5
$\begingroup$

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.

$\endgroup$
8
  • $\begingroup$ (1) This is not a great answer. $\endgroup$ Jan 29 at 14:34
  • $\begingroup$ (2) But it is a good answer, and I upvoted. $\endgroup$ Jan 29 at 14:34
  • 1
    $\begingroup$ (3) The one you linked to in a comment under the original post, now that was a truly great answer. $\endgroup$ Jan 29 at 14:35
  • 1
    $\begingroup$ 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. $\endgroup$ Jan 29 at 15:14
  • 1
    $\begingroup$ @WillG Succinctly, if you know the distinction: Raising WorkingPrecision lowers round-off error. Raising PrecisionGoal lowers truncation error (up to the limits of WorkingPrecision). $\endgroup$
    – Michael E2
    Jan 29 at 23:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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