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

@davtrs Is this what you really wanted to plot---a bunch of disjoint line segments?

I'd like to point out that in section 1.2 of the book, "The Maple Interface", the author advocates for the use of Maple Input (aka 1-D Input) and advocates against 2-D Input. His main reasons are the same as mine.

@mmcdara 

You wrote

• I didn't know about this way to access an entry of a table.

I didn't know about it either until you posted your Question. I was trying to figure out how it was possible that g worked while f didn't, and thus the possibility of the existence of the "feature" in question occurred to me. I think that there's a good chance that no-one was aware of its existence other than the person who programmed it and the person who ordered that person to do it.

• [Is it] some kind of undocumented feature?

Yes, if you mean undocumented feature in the specific technical sense of that term. There are many words used in computer-programming jargon to make fine distinctions between various types of features. I think that the best of those words for this case is wart: "A small crocky feature that sticks out of an otherwise clean design. Something conspicuous for localized ugliness, especially a special-case exception to a general rule."^[1]

• It has one funny consequence: for instance (attached file), the syntax T:-N (where T is a table and N one if its indices) avoids using eval to visualize T[N] if N is itself a table.

Yes, I had already noticed that. For goodness sakes, don't ever make use of that except possibly for humor.

I think that it's acceptable (but not optimal) to make use of this wart to access members of table-based packages, but unacceptable to use it for any other purpose (such as table lookup) other than possibly for the sake of humor.

[1] From the famous Jargon File: http://www.catb.org/jargon/html/W/wart.html