Hello, Series[] returns its result in a symbolic form, so that I understand the result has an "infinite" acuracy. The question is what to do next in order to convert this result to a preselected finite precision and (most importantly) maintain this precision in subsequent calculations. You write "Any subsequent calculations with each of those might indeed maintain 100 digits of precision (depending on the calculations)". What does this mean? Why "might" and not "will"? Why "depending on the calculations"? In ordinary calculations using IEEE754 floating point numbers, every arithmetic operation adds some error, so that in the worst case, after many operations, the precision of the results gradually deteriorates. But according to some manuals for MATHEMATICA, if I use floating point numbers with a a user-selected precision, the precision of the calculations will be adaptively maintained to ensure a selected level. I presume MATHEMATICA uses some mystic method of adding more bits to numbers, if needed. But how to make this happen? Should I use SetPrecision or N, or both (and how)? Please show me using my example. Please note also that I use Integrate[]. I don't use NIntegrate[] so that the issues of AccuracyGoal, PrecisionGoal, and WorkingPrecision do not arise. Lesław

If you have an infinite precision quantity, then I believe applying either SetPrecision or N will produce the same result. As for maintaining precision, I would think that would totally depend on the operations you're going to perform. Unfortunately, I don't know the implementation details of how Mathematica handles precision. I suspect that, yes, extra digits are carried around in an attempt to maintain precision, but I don't know how to explicitly exploit that. I have noticed that extra digits are used, and I generally assume that outputs are correct up to the precision of the inputs, unless I have reason to suspect otherwise. But I'm not an expert on numerical precision, and I would think that if you want high confidence in the actual precision of your results, then you'd need to analyze your specific sequence of computations carefully. (The term "precision" is taking on different meanings here, but hopefully it's not too muddled.)

As for your specific example, you didn't provide F nor s1, so I can just provide generic guidance about Integrate. I would start with N[Integrate[...]...]. Then I would consider NIntegrate[...] and epxeriment with the relevant options. Only then would I consider trying to manage precision "manually" by specifically setting the precision of the inputs. If it got to that stage, I would experiment with different levels of precision until I was satisfied with the results.

But honestly, I hope someone with more sophisticated knowledge of numerical computation will jump in here. I was mostly trying to explain the semantics of the functions you were asking about; I don't claim any expertise in how to analyze computational error.

... if I use floating point numbers with a a user-selected precision, the precision of the calculations will be adaptively maintained to ensure a selected level.

N[f[x], precision] adapts precision if f[x] has infinite precision, but f[N[x, precision]] does not. The error will propagate through f[N[x, precision]].

SetPrecision takes all numbers and mathematical constants it sees and assigns them their numerical equivalents at the requested precision. Then the expressions containing them are evaluated, and error is probagated (assuming one did not use MachinePrecision as the second argument). N by contrast attempts to evaluate the entire expression to the requested precision (same caveat). Here is an example.

ee = Sin[10^5];
prec = 4;
{InputForm@N[ee, prec], InputForm@SetPrecision[ee, prec]}

(* Out[829]= {InputForm[0.0357487979720165093`4.], InputForm[0``0.0]} *)

Notice that all precision was lost in the second case, where SetPrecision was used.

There are situations where the attained precision on application of N to a numeric expression might not be correct. The cause I am aware of is in evaluation of special functions, in cases where the error estimates might be off. I believe this is a rare situation though.

Using N in a symbolic computation is a different fish. For example, code in definite integration needs to account for presence of singular points that might only be approximately known. Code in functions such as Together (used by Integrate) might use Rationalize or take other steps just to avoid crashing; such code was not designed for handling approximate numbers (and indeed, the literature on this is far from complete).

With all this in mind, your approach seems reasonable, but I cannot offer any guarantee. Moreover I am fairly sure it would require careful numerical analysis of the inputs and results in order to provide such guarantee.