@gaurav_rs Your input expression F1 has (if I counted correctly) 33 digits of precision in its coefficients. If you have Digits set to 10 when you input the expression, of course you'll get inaccurate results. My fast symbolic method can get you the full 33 digits of accuracy, which, of course is the most that you can expect given the coefficients. This accuracy can be confirmed by numeric integration, which is very robust for accuracy.

restart;
Digits:= 35:
F1:= #Lengthy input expression omitted.
#Fully symbolic integration (fastest way):
CodeTools:-Usage(
   int(fnormal(F1), [theta= Pi/4..7*Pi/4, r= 0..1])
);
memory used=57.39MiB, alloc change=-4.00MiB, cpu time=734.00ms, real time=736.00ms, gc time=125.00ms
                                                   12
           -1.1160010071917964702041524480427751 10  
#Inner integral symbolic, outer integral numeric:
CodeTools:-Usage(
   int(int(fnormal(F1), theta= Pi/4..7*Pi/4), r= 0..1, numeric)
);
memory used=169.19MiB, alloc change=140.01MiB, cpu time=1.59s, real time=1.81s, gc time=125.00ms
                                                   12
           -1.1160010071917964702041524480427751 10  
#Same thing with order of integration switched:
CodeTools:-Usage(
   int(int(fnormal(F1), r= 0..1), theta= Pi/4..7*Pi/4, numeric)
);
memory used=0.73GiB, alloc change=51.13MiB, cpu time=5.09s, real time=4.83s, gc time=843.75ms
                                                   12
           -1.1160010071917964702041524480427751 10  
#Fully numeric double integration:
Digits:= 15:
CodeTools:-Usage(
   int(fnormal(F1, 35), [theta= Pi/4..7*Pi/4, r= 0..1], numeric)
);
memory used=277.90MiB, alloc change=168.00MiB, cpu time=5.03s, real time=5.01s, gc time=234.38ms
                                         12
                     -1.11600100719180 10  

@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?