@vv Regarding &where: No, there's no strong reason to use it. Indeed, I decided against it, and I changed the Answer to not use it.

Regarding eval: This is a common and unfortunate problem. It's caused by there being, essentially, two very different commands both named eval. When eval is passed a single argument (even if that argument is a two-member expression sequence), it uses the first meaning of eval: changing names into the expressions that they are equal to. You can get around this by using value(Eval(t)) or, as you noted, eval[recurse]. With both of these forms, it knows that you mean the more-modern meaning of eval: evaluation of an expression at a point.

On the Maple 2016 help page ?eval, what I'm calling the "first" meaning is documented via the fourth and fifth calling sequences and paragraphs 7 - 13 of Description. I call it "first" because this usage existed long before the more-modern usage.

@sunit It's illegal to use indexed names as procedure parameters. But you can do this

(T0, T1, T2)-> R(T1,T2)*sin(omega*T0+phi(T1,T2))

or, if you want subscripted names, you can do

(T__0, T__1, T__2)-> R(T__1, T__2)*sin(omega*T__0 + phi(T__1, T__2))

@toandhsp Were you using 2D input? If so, try it with 1D input (Maple Input).

@sunit So, why are you just ignoring my solution?

@Kitonum 

The following procedure does the same thing, easier I think:

FactoredParametric:= proc(A::Matrix)
local B:= selectremove(v-> v[-1]<>0, LinearAlgebra:-NullSpace(A)), k, v;
     v[0]+add(_C[k]*v[k], k= 1..nops(B[2])),
     [v[0]=-B[1][][..-2], seq(v[k]=B[2][k][..-2], k= 1..nops(B[2]))]
end proc:
     
sol:= FactoredParametric(R);

The solution in this form has the benefit of being directly evaluatable:

value(Eval(sol));

@Adam Ledger Yes, the parameters nn and xx are transcribed to the locals n and x. Since the locals will be used more often, it is natural that the shorter names will be used for them. The name nn has nothing to do with two digits. It is just a single variable name. Variable names can have any number of characters.

See ?Psi for the significance of the first parameter to Psi.

Be careful about the distinction between parameters and arguments. In the following code, x is a parameter and 3 is an argument:

Sq:= x-> x^2:
Sq(3);

@John Fredsted The problem with your method is that it doesn't handle the x[1](T[0] - tau_1, T[1], T[2]).

@rlopez A "naked" expression sequence (possibly even an empty (NULL) expression sequence) enclosed in parentheses does have some limited meanings in Maple: It can be either of the operands of =, <, <>, .., <=, or ::; and it can be an entry in a table or rtable. I've noticed that the 2D Input occasionally doesn't recognize or respect these meanings and acts as if the parentheses weren't there.

I had assumed that the OP had wanted to take the equation A = (1,2,3) and assign it to a variable. This can be done via:

EqA:= A = (1,2,3);

Note that this is different from

SeqA:= A = 1, 2, 3;

The former is an equation whose left operand is A and whose right operand is (1,2,3); the latter is an expression sequence whose first member is the equation A=1 and whose other members are 2 and 3.

You are correct that outside of these contexts, the parentheses have no meaning.

@Adam Ledger

All Maple computations are self-contained in your computer. There are no "servers" in the sense that you mean.

@Kitonum Okay, okay, alright, of course, you have a point, but you're splitting hairs. I'll rephrase it to "A true result from is is as trustworthy as any other Maple result." In other words, the false positive result that you showed isn't a result of a bug in is.

And to split your hairs back at you, what you did can't be done for every bug. It can only be done for those bugs where Maple returns a wrong but meaningful result given meaningful input. It doesn't apply when

• Maple fails to return an error message when it should
• Maple returns an error message when it shouldn't
• Maple crashes
• infinite loops

@Earl I don't doubt my computed value of DthetaZero---I can get it other ways, and it's the same as what everyone else got---but I do doubt the validity of my solution technique. The value of T that I computed was just based on round-off error. By increasing the accuracy of the computations, I can make it as large as I want. See my Answer below.

@mskalsi Take apart my command. Study what each part does. This'll be much easier to understand than frontend, and will help you understand what frontend does.

@Adam Ledger If you want to see evalf code, then you just need to specify the function name. For example, to see the code for Psi, do showstat(`evalf/Psi`). The only one that I'm aware of being kernel code is `evalf/hypergeom/kernel`. On the other hand, it seems that the evaluation of most of the special functions ultimately make a call to this one. For numeric integration see `evalf/int`.

@Adam Ledger The entire on-board documentation of is consists of six short sentences on page ?assume. It's a very old part of Maple (at least 20 years), and I don't recall there ever being an announcement that it had been updated (not that every update is announced). The validity of is is a frequent topic of debate here.

It should return FAIL in this situation (assuming that the identity is true for all complex values of the parameters under the assumptions). That's what it's supposed to return if it can't prove or disprove the algebraic truth of the statement. It might be interesting to trace the execution and figure out how it ends up returning false; and it might be overwhelming. Certainly I've seen many situations where it incorrectly returns false.

As far as I recall, a true return from is is trustworthy.

@Earl The Question that you asked is theoretically interesting for this ODE, and there is something very strange and unstable about it that's worth studying (I'll give an Answer below, eventually). However, I'm writing this Reply to cast doubt on the relevance of the ODE to the real-world situation that you describe. The ODE can be rewritten as

diff(theta(t),t$2) = sin(theta(t))*(cos(theta(t))-9.81)

Now what is this 9.81? Is it the acceleration due to gravity? So the units are m/s^2. How is it valid to subtract that from the cosine of something? There must be an implied coefficient of 1 m/s^2 in front of the cosine. So what in the real-world situation has an acceleration of 1 m/s^2?

Now look at the left side. Its units must be radians/s^2. So there's an implied coefficient of 1 radians/m in front of the sine. What does that 1 radians/m represent?