@David Sycamore Rather than make a comparison of ithprime and nextprime (because I don't have time at the moment to construct a fair comparison of the two), I made the following test, which shows that for the range of primes that you're working with (I think), the nextprime method iterates through them at more than 30,000 primes per second  on my machine:

restart:
P:= proc(P::posint, n::posint)
local p:= P;
   to n do p:= nextprime(p) od;
end proc:
CodeTools:-Usage(P(3*10^8, 3*10^4)):
memory used=173.43MiB, alloc change=0 bytes, cpu time=906.00ms, real time=902.00ms, gc time=46.88ms

@Gabriel samaila If you make Nt=0 first, that will eliminate the term that has Nb in the denominator. After that, you can make Nb=0. Since the four unknown parameters now have numeric values, there's no need use fsolve; you can just use the procedure Solve that I already posted. I've done this, and I still get values for C__f completely different from those shown in Table 1.

@Gabriel samaila I haven't tried it yet. I think that you mean making Nb a small value, not Nt? I will try it.

@tomleslie My experience is that not putting restart in its own execution group is more likely to cause a problem with interface commands than with others. I think that it has something to do with synchronization between the GUI and the kernel.

@Rouben Rostamian 

Good workaround. Vote up.

My guess about what's causing the error (just a hunch) is that it happens when the size of the window needs to be expanded for some reason that Explore didn't originally anticipate. In this case, the superscripted exponents cause a slight expansion in the vertical extent of the plot.

Explore is by far the single largest procedure that I've seen written in Maple. Listing its code into a string with sprintf, the string is 56,591 bytes. It has several magic formulas for estimating the height and width of the window needed.

@samira moradi For example, the following command will find all the roots in the interval 0..99 for all integer B in 1..30. This command takes about 5 minutes to execute:

Lambda:= table(
   [seq(
      j= 
      Student:-Calculus1:-Roots(
         eval(F[lambda[i]], [y= 0.9, k= 0.003, B= j]), 
         0..99
      ),
      j= 1..30
   )]
);

Then Lambda[25], for example, will be a list of the 55 roots for B=25, and Lambda[25][30] will be the 30th root for B=25.

@samira moradi The command Student:-Calculus1:-Roots will give you all the roots within a bounded interval.

@samira moradi Given that mostly trig functions are used, I strongly suspect that there are an infinite number of roots.

@nm You wrote:

• Not that I even know what it means being a newbie in Maple.

As I've told you before, setting kernelopts(opaquemodules= false) makes the syntax A:-B apply to both exports and non-exported locals of module A; whereas the default setting, true, means that it applies only to exports^[1]. I guess that the only significant thing about it that I didn't say before is that that is the only purpose of opaquemodules.

[1] The exception is if A is literally the keyword thismodule. This can only be used inside a module, and then thismodule:-B can refer to both exports and non-exported locals of the current module regardless of the setting of opaquemodules.

@tomleslie Thanks, I didn't know that. That's very useful. I hope that that setting can be saved for future sessions.

This case shows precisely why help pages should not be written in 2-D Input.

@vv I don't think that we should rely on int for this. It should be reserved for cases where other methods fail.

I don't know whether this is appropriate for your application, but you can iterate through the primes with nextprime rather than ithprime. The details of this are given in an Answer below. For an unexpected reason (idiosyncratic to Maple and explained below), iterating with nextprime is many, many times faster than with ithprime.

@vv Thank you for the example. It let me find a small bug in the code: I had used expand(..., 'symbolic') in one place, but there is no symbolic option to expand. I changed this to simplify(..., 'symbolic'). (The change has been put into the code window in my Answer.) With that change, my procedure easily computes the integrals needed for your example (using method= ln). However, the constant C it produces appears superficially to depend on x and y. It actually doesn't depend on them, but I can't get Maple to verify that.

Of course, the best approach for this example is to just factor and use algebraic methods such as those that others have posted.

@nm I agree that

expr:= arcsin(x)/(sqrt(1-x^2)*y^2);

was the hardest case. But my procedure can indeed separate it! Try

Separate(expr, method= tryhard);

What makes you think that Maplesoft can achieve with a "build-in" function something better than we can make here?