@vv It's essential to prevent the "naked" if expression from evaluating. It would be safe if it used the `if` operator. To prevent it from evaluating, put it in a procedure via unapply:

PP:= unapply(convert(P, `if`), x);

Now it's safe to lprint it or to do anything else that you would do with a normal procedure.

Perhaps it's because of the volatility of the naked expression that this command is undocumented. The general command has to use an if statement rather than an `if` function call because the latter can't handle elif. Any piecewise with more than three arguments will require an elif.

@Ronan The short version of Acer's informative Answer is that the intended command for making the Matrix evaluate is rtable_eval(M) rather than simplify. But don't use M:= rtable_eval(M), for then you'll lose the ability to go back to the original M when you unassign a.

@Stavros You just need to change the file name in the following code to a name appropriate for your computer.

fid:= fopen("C:/Users/Carl/desktop/GL4.2.txt", WRITE):
map[3](fprintf, fid, "%s\n", GROUP):
fclose(fid):

@MrYouMath You should have enough reputation now to give John a thumbs up. If you don't, there's a bug. 

So psi is a function of two variables, x and eta, right? Do you want a contour plot of psi?

@mskalsi Clearly the package isn't installed. Your libname is telling Maple to look for the files on your E: drive. Is the .mla file located at that place on your E: drive?

@mskalsi At this point, you should be able to use the commands in the package "DGApplications". If it's organized like most packages, you should be able to enter

with(package name);

@Markiyan Hirnyk A timing so small isn't valid unless you use the iterations option to CodeTools:-Usage. This is because the resolution (or granularity) of the Maple clock on Windows computers is 16 ms (to be exact, it's 1/64th of a second). That means that a time less time than 16 ms is impossible to measure in a single iteration. It is only by averaging over many iterations that a valid time less than 16 ms can be measured. The iterations option performs that averaging.

So, please redo the timing using this option so that we'll have a direct comparison on a single computer of the Mathematica and Maple times.

PS: The following simple experiment proves the granularity of the clock.

restart:
st:= kernelopts(cputime):
t:= kernelopts(cputime) - st:
for k while t < .1 do
     T[t]:= [][];
     t:= kernelopts(cputime) - st
end do:
{indices(T,nolist)};

k, nops(%);

So, the time was measured 29,417 times, yet only 7 distinct measurements were recorded.

@vv Good work; vote up. And I think that your code exposes the algorithm better than my matrix-multiplication version. If your computer and Markiyan's are comparable, then this is now significantly faster than the Mathematica.

When a global name is used in a procedure, but no assignments are made to it in that procedure, then there's no need to declare it global, nor do I think it's desirable to do so. If it were, you might as well declare all Maple library procedures as global.

@vv The inner proc is compilable.

The Task model seems inappropriate for the OP's purpose, which is performing a computation three different, independent ways. I see the Task model as being fundamentally recursive. I've implemented Roman's idea in my Answer below, but in the basic Threads model rather than the Task model.

@Axel Vogt The title was my fault, and I've changed it now. I'd assumed that the OP's final line of output was what was being claimed as erroneous, as is usual with a bug report.

@Mariusz Iwaniuk I'm sorry. Your inappropriate use of evalf threw me off. I thought that you meant that the bug was that evalf didn't return 0 like the others. Usually when reporting a bug you should make the final line of output the one that shows the bug, unless some other line of output is explicitly pointed out.

Do you have any initial and/or boundary conditions?

The command evalf doesn't supercede value. After you apply evalf to an inert indefinite integral, you still have an inert indefinite integral. Note that the integral sign is grey, not blue. There is no bug.