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

@acer Yes, the change only explains why procedure g works. The fact that g works while f doesn't leads to confusion if one is trying to follow the documented syntax.

My previous Reply was meant totally as an aside to provide additional information and not in any way meant as a criticism of your Answer.

My guess is that the hack was put in to help obscure the distinction between table-based and module-based packages. A side effect is that it also affects any table with a name index. Perhaps no harm will come from this.

@acer Furthermore, the semantics of :- have changed (without notice!) such that if T is any table (not necessarily a package) and N is any index of T of type name, then T:-N is the same as T[N] on lookup! And even weirder: If T:-N is being assigned to, a new and difficult-to-access index 'N' is placed in T. Execute this:

restart:
T:= table([N=7]):
T:-N;
T:-N:= 11;
T:-N;
T[N];
T['N'];
T[''N''];
{indices(T)};
eval(%);

These changes are not supported by the help page ?:-; indeed that page contradicts the new behavior. My guess is that whoever put this hack in the kernel was ashamed of having done it.

This explains why the OP's procedure g works even though orthopoly is a table.

@Markiyan Hirnyk 

Your example raises an interesting question. Should a proposed solution to an ODE without specified initial conditions be considered correct if it doesn't include arbitrary constants of integration? Apparently the author of odetest had no consistent answer to that. Note that if you simply remove C1 rather than replacing it with 1 (equivalent to setting C1=0), odetest still fails. On the other hand, odetest(y(x)=0, diff(y(x),x) = y(x)) passes.

I still think that my Answer provides an effective workaround (rather than a complete solution) for the situation presented by the OP. The situation is afterall a bug.

@tomleslie Threads:-Sleep works fine in ordinary (non-multi-processing) code. Its use does not require the use of any other command from Threads.

@digerdiga Can the variable x be assumed to be real? Knowing that would substantially reduce the complexity of the problem.

@taro I'm not saying that the literal expression D(x) will return 0, nor am I saying that the statement "D(x) always returns 0" is true. But all of these do return 0:

D(5);                              #or use _any_ other number
eval(D(t), t= 5);             #Use _any_ name other than x
eval(D(t), {l= 3, t= 5});  #                    "
eval('D'(x), x= 5);
eval('D(x)', x= 5);

And these plots will be identically 0 over any range:

plot(D, -5..5);
plot(D(t), t= -5..5);

So, I, myself, am not saying "D(x) always returns 0". Rather, I'm saying that repeated attempts of the type shown above would reasonably lead a new user to say "D(x) always returns 0". I can't fault that user for thinking that. Given the experience of the examples above, it seems reasonable in its own right. Plus that user may have been misled by help or examples (not necessarily official help or examples) that make one think that f(x):= ... is a proper way to define a function.

So, do you now understand what I said in my previous Reply?

@Kitonum Well, it's not just a name. Surely a user of your experience level knows that D is a library procedure, the differential operator. So, whether or not one assigns a value to D(x), all these: D(0.1), D(0.01), D(any specific constant), will return 0 due to D's original definition as the differential operator. This leads the OP to believe and to say (with good reason!) that "D(x) always returns 0", even though the literal expression D(x) may return some other value.

The upshot or takeaway or moral is: Don't use the syntax f(x):= to define a procedure or function. It's not safe, even though 2D input allows it.