@vv Regarding efficiency, I don't think that there's much difference one way or the other. Assignment statements are replaced by argument passing; local variables are replaced by anonymous procedures. I simply find such code to be immensely esthetically pleasing. It gives me great joy and relaxation to rewrite procedures this way. In the process I gain a much-deeper understanding of the underlying algorithm.

I agree that convert(,,,, If) is better than convert(..., ```if```). It's difficult to remember how many quotes are required for such expressions, and the syntax for embedded quotes varies from one language to another.

Now we can make this into a legitimate convert procedure. I've also rewritten your code in my preferred, perhaps-obfuscating, functional-programming style.

`convert/``if```:= e->
     subsindets(
          e, specfunc(anything,piecewise),
          e-> (()-> '`if`'(`if`(
                         nargs<4, [args, `if`(nargs=2, 0, [][])],
                         [args[..2], thisproc(args[3..])]
                         )[]
                    )
              )
              (op(e))
):

It's use on your examples:

convert(piecewise(x<1, 10, x<2, 20, x<3, 30), ```if```);

     `if`(x < 1, 10, `if`(x < 2, 20, `if`(x < 3, 30, 0)))

f:= piecewise(x < 0, piecewise(y < 0, 0, 1), piecewise(y < 0, 1, 0)):
convert(f, ```if```);

     `if`(x < 0, `if`(y < 0, 0, 1), `if`(y < 0, 1, 0))

@vv Excellent. Vote up.

@vv Yes, any piecewise can ultimately be translated into an `if` expression by imbrication, but it's more complicated, not a one-for-one substitution of arguments as with the if statement (see my footnote in the Answer). Maybe it can be done with something akin to foldr that skips two arguments instead of one. And that'll be wrapped in subs(IF= `if`, ...) in the same manner as CartProdSeq uses subs(S= seq, ....).

So here's the challenge (open to all readers, of course): Write a conversion procedure the converts piecewise to `if`. Preferably it should use no "hackware". I think that the first step is to write a new version of foldr called foldr2 (which is to foldr as map2 is to map). Note that for any piecewise with an even number of arguments, you'll need to add an 0 as the final argument.

Before we can answer your question, we need initial conditions.

Here's the start of an Answer: Here's your system with corrected syntax. I changed I to J because I is essentially reserved for sqrt(-1). (We can use I if you really want, but I don't think that it's worth the hassle.)

ODEs:=
     diff(x(t),t) = y(t)-b*x(t)^3+a*x(t)^2-z(t-tau)+J,
     diff(y(t),t) = c-d*x(t)^2-y(t),
     diff(z(t),t) = r*(s*(x(t)-beta)-z(t))
;
ICs:= NULL; #You need to supply these.
params:= [a= 3, b= 1, c= 1, d= 5, s= 4, beta= 1.6, r= 0.6e-2, J= 3.0]:

Once you supply the initial conditions, the command for solving the system will be

dsolve(eval({ODEs, ICs}, params), numeric, ...perhaps some other options...);

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