@nm 

The keyword function used as a type in your procedure's header is too restrictive. Maple's definition of function as a type is perhaps idiosyncratic (i.e., specific to Maple in a way that deviates from commonly used definitions), so having made this mistake is quite understandable. Your example cos(x*y) is a function but cos(x*y) + sin(x*y) is not. See ?type,function. If you change function to algebraic, then it's fine. This type, algebraic, is also defined idiosyncratically, because even transcendental functions^[*1] such as cos(x*y) are considered algebraic by Maple (but not in standard mathematical language, where transcendental and algebraic are dichotomous).

An unrelated recommendation is that you change vars::list to vars::list(name).

[*1] Note that I intentionally used function here in one of its standard mathematical usages, just to show the contrast. In even another usage---in a generic computer-science context---function often means essentially the same thing as what Maple calls a procedure.

@vv I don't know why you've attached this Reply specifically to my Answer.

It's impossible to properly understand what's going on here without addressing quantification.  For example, the command is applies universal quantification to all variables. It's companion command coulditbe applies existential quantification. If you had replaced is with coulditbe, then you'd have true implies false.

Perhaps you do not realize that the OP has extensive CAS experience (30 years using Mathematica, 29 years using Maple, 16 years on MaplePrimes). He is not a newbie who has simply stumbled upon this anomaly and is looking for a simple explanation. I believe that he wants a broad discussion of the formalism.

Almost certainly your problem is due to a programming error that'd be easy to correct if we could see the code. It's unlikely that it's due to an actual memory limitation, and, even if it is, it's likely that we could figure out a way around it.

Perhaps it would be easier for you to simply present here the combinatorial problem rather than the code.

This is a boundary-layer BVP. It can only be solved numerically, and that requires supplying numeric values for all the parameters. You also need to treat infinity as a parameter and give it a numeric value, such as 10.

I've seen this phenomenon also, but I didn't care enough about it to investigate what was causing the difference.

@nm Your Answer (both the plot and the integral) treats y=0 as one of the boundaries of the region. It is not.

Are you capable of even reading what you have posted? And do you care? The questions are obvioiusly incomplete. The right sides are cut off, and the essential information from "figure Q4a" is completely missing.

Do not check off all the product boxes. This is extremely rude, and I'm inclined to have your account flagged for deletion.

@JAMET You wrote:

• Sorry your suggestion doen't work.

Tom's Answer (vote up) doesn't contain any "suggestion", and thus it could neither be said to "work" nor not to work. The Answer explains the cause of the warning message, not how to correct it. Since the cause is fundamentally mathematical rather than being due to your coding, a bug, an anomaly (such as complex floats with infintesimal imaginary parts), or a Maple idiosyncracy (such as its rightful refusal to store nonreal numbers as real plot coordinates), this Answer is acceptable to me as an official Answer.

@tomleslie I don't see any connection between the Question and the Kronecker delta function. The integer first argument to Dirac is the derivative order.

@robertocooper If you take the worksheet as posted in your Question and only make my changes 1 and 3 and then hit the !!! button to "execute entire worksheet", I guarantee you that it will not work. Please try again. It can't possibly work because t will not be assigned any value. After a long wait, plot3d will return a warning about that and an empty plot.

If you assign t=1 in the eval, then it will "work" in a sense, but it's a very bad thing to do because it's very prone to error. If you do U:= (x,y,t)-> test where test is some variable which has been assigned an expression containing x, y, and t, then those variables are not parameters of the function U, they're just global variables. Indeed U couldn't even be considered to be a function of x, y, and t. Notice that your line U(1, 8, 1) doesn't substitute 1 for x or 8 for y!

In order for the arrow -> to work, all references to the parameters on its left side must explicitly appear on its right side; in other words, the references to the parameters can't be hidden in some other variable such as test. If the variables are hidden, then you need to use unapply. If they're explicit, the arrow is much more efficient. (The inefficiency is only in the function-definition step, not in the uses of the function.)

While I was typing the above, you added a question about a "multi-function" b[0]. There are a vast number of ways that that can be handled, but every general solution that I can think of is too arcane to descibe to you at this point in your Maple learning. I suggest that at this point you simply define them as two separate functions.

Your Question doesn't make sense. Are those two separate questions? If so, are they related somehow? I don't understand "convert this value in single"; it doesn't mean anything in English. Do you mean that you want to separate the real and imaginary parts of that number?

Your equation has four variables. There is no way to find their values. Generally that requires that there be the same number of equations as variables.

@Kitonum My statement "There are no real roots" was not based on fsolve's inability to find a real root. I would never assume that fsolve not returning a result meant that the result didn't exist. Indeed, it very often means that it found an approximate root but was unable to refine it to Digits precision.

My statement was based on several plots of N:= numer(P1) and its derivative. The denominator of P1 is obviously strictly positive, and hence irrelevant to the root-finding. N is essentially a degree-18 polynomial: There are some arctan factors in some terms, but they are essentially constant considering the huge range of the polynomial, so safe to assume arctan= -1 (just for the purpose of deciding whether there's a real root). The plots and derivative indicate that N has a unique local minimum that's positive.

@Christian Wolinski Even after defining the aliases your way, the following will not work:

for k to 4 do op(a[k]), op(u[k]) od;

Yet this is exactly what the OP wants to do: Use a variable to index the aliased functions. It's not a bug; by design it will not work.

@BennyMopps

 $ is the repetition operator. `$`~ applies it elementwise to each member of a list.

@Preben Alsholm My interpretation of the OP's intended meaning is identical to Kitonum's. Of course, I also immediately realize that this is ambiguous.