@gvelbu12 Yes, that's all obvious. But I don't know what to do to get the bifurcation plot.

@Joe Riel Or better yet

f:= (i,j)-> OrderB(0, i, j+3);

@spalinowy I think that you mean Joe Riel. I didn't write a solution to your problem.

@gvelbu12 So, if I'm interpretting this correctly, you want a plot with tau on the horizontal axis and the accumulation points (i.e., attractors) of the sequence t[k]=x(t[k-1]), t[0]=0 on the vertical axis. Is that right?

The problem is that the range of x(t) is approximately -1..2.6, and Maple can't evaluate the solution further left of -.49883899, probably due to a singularity.

@farahamirah There are only two solutions to D11 = -delta*D11: delta = -1 or D11 = 0. Neither solution leaves both D11 and delta undefined.

@spalinowy You need to use multiplication operators. In 2D input., you can use a space as the operator. 

See ?IntegerRelations,LinearDependency.

@gvelbu12 In that previous Answer of mine, x was simply a variable. In your case x is a function, x(t). The situations don't seem comparable unless you were to fix a specific value of t.

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