@HeiniKlum I changed the title for you. Hopefully I captured your intent.

@gaurav_rs How do come up with two decimal places? My result is far more accurate than that. I guarantee you that the discarded Bessel terms wouldn't change the 10000th decimal place of the result.

What you show is a standard Taylor polynomial (including order-of-approximation term) for sin centered at 1, such as you can find defined in any calculus textbook.

@Carl Love Well?? Does it work??? Since you didn't post the function, I have no way of knowing whether my idea corrected the problem unless you tell me.

@acer A small correction: The remainder is the fractional part times the divisor.

Yours is the third report of this problem that I've seen here. Someone said it was due to a "cracked" (illegal) copy of Maple. Since neither person reporting the error denied that, I'm inclined to believe it.

@nm Perhaps you didn't notice that the OP is asking about evalhf, not about evalf.

Yes, it is possible, but the way that I would do it would differ depending on the purpose. Is the purpose simply to make a neater display of the final results? Or will the truncated results continue to be used within evalhf for further computation? And, if the latter, is it necessary that the truncation be to a value that is exactly representable in base-10 (which Maple's software floats use), or is a base-2 representation (as used by evalhf) okay?

If the purpose is to speed up the computations within evalhf, I can assure you that truncation will not help with that.

@vv When the OP says "all variable[s] tend to infinity," I think that they mean something akin to an asymptotic series.

@Magma It's not your fault. The help page is totally unclear about what 'r' and 'd' are for and whether either can be used without the other.

@Magma Anyone who's taken a first course of linear algebra should be able to tell you that the maximum number of linearly independent columns of an 8x16 matrix is 8, hence there's at least 16 - 8 = 8 columns that are dependent on those independent columns. So, your answer 7 is utterly wrong; no computation or any reading of your worksheet is needed to know this.

I like your questions (notice the vote-ups that they've received), and they're not too many. Please don't feel inhibited about asking them.

@radaar You asked:

• So if the number of terms in the array is small it is better to go with the code which I have written. is that so?

No, and I don't see how my Answer leads you to believe that. I merely said that your code was accurate, not that it was efficient. If the number of terms is small, use add; if it is large, use Threads:-Add. There is no reason in Maple to ever use a loop to repeatedly update a sum of independent terms if the number of them is known at runtime.

@radaar So, doing 10000 numeric double integrals in under 3 seconds is not fast enough for you?? Seems fast to me. You may able to get faster by finding the externally compiled code that this integral uses and calling it directly.

@Joe Riel 

Joe,

I noticed that you didn't address the issue of thread safety. Is that because you know that this type of integration is thread safe?

@opus64 Can you show an example equation that your command works on? It can't work in general because it has too many op commands. Try it on Sum(x[i], i= 1..9) = Sum(y[i], i= 1..9) to see what I mean.

Did you try my command? Why no comment? It's intended to work in more general cases.