@max125

Yes, the purpose of the subs(y(x)=y, ...) is so that y(x) will be treated as a regular variable (aka, a name).

Yes, without any knowledge of the nature of the function y(x), it is impossible to solve any equation containing y(x) for x. It may still be solved for y(x) or another variable.

The process of treating a function (or other expression) as a simple variable is common enough that there's a command just for it: frontend. In this case,

frontend(solve, [deq= 3, y(x)])

works. Its default action is to treat all functions appearing in the square brackets as simple variables. In this case, the only function is y(x). This can be controlled with options. See ?frontend.

Meaning of RootOf: If f(_Z) is any algebraic or transcendental expression containing variable _Z (and possibly other variables), then RootOf(f(_Z)) means "the set of all _Z in field F such that f(_Z) = 0." Here, F represents the algebraic field of interest. Usually this is the complex numbers, although Maple can deal with other fields as well. Maple often responds with a RootOf  when it can't explicitly determine the members of that set. There's only ever one bound variable in a RootOf, and it's always _Z.

Start each repetition of the computations with the command

restart;

by itself, on its own line, in its own execution group. Beginning with restart is good advice for any Maple session. If you still experience the erratic behavior that you described, please repost here including an upload of the worksheet.

On Github, there's a probabilistic programming language called Hakaru that's written partly in Maple and partly in Haskell.

What do you mean by "add support for" non-plaintext worksheet files .mw and .mws? I understand what "support" for plaintext files like .mpl means. And if you're going to do worksheet files, you might as well also include .maple, the newest member of the family.

@rahinui There are 4 types of remember tables that can occur in Maple procedures (if you count absence of a table as a type). This is mostly^[1] controlled by the options (if any) at the beginning of the procedure. Every procedure has exactly one of these types:

• Regular (option remember): All computed values are remembered until they are explicitly removed.
• System (option remember, system): Just like the above, but the table is also cleared by gc() (whether automatic or explicit).
• Cache (option cache): The table has a maximum number of entries (that you can set, if you want). When it's full, new entries replace the oldest ones. These tables can also have "Permanent" entries, which are explicitly set.
• No remember table (there is no corresponding option): The procedure is executed whenever it is called.

I am considering a cache table a type of remember table. The documentation seems to distinguish these, but in name only: There's not much difference between them (other than as I described above) as far as I'm concerned.

Regardless of the options, a procedure doesn't acquire a remember table until there's actual data to store in it.

Regardless of the options (or their absence), entries can be added to the table of procedure P using the syntax P(...):= ..., where the "..."s represent any expression or expression sequence, including NULL. If the procedure doesn't have a table, one will be created. If the procedure doesn't exist, this will create it.

This procedure checks whether a procedure has a remember table:

HasTable:= (P::procedure)-> evalb(op(4, eval(P)) <> ()):

And this one checks whether a procedure has the option for one:

HasTableOption:= (P::procedure)->
   evalb(({op(3, eval(P))} intersect {'remember', 'cache'}) <> {})
:

^[1]"Mostly" because there's also direct-assignment: P(...):= ....

(to be continued)

@Arny

Surely you're closer to the result than you were before I intervened!?

I may not being understanding the "Physics" aspect of this correctly, but how could the result possibly be anything other than infinity? The integrand doesn't even approach 0. Simplify it to the 1D case, and perhaps you'll see that. I'm suggesting this as a "thought experiment" at the moment; you still have some syntax issues that we can address later.

@Britzel Could you give me a simple example of a functional F of a single argument f (itself being a function of a single real variable x on a closed interval) that you might want to minimize?

@Christian Wolinski First vote up is mine.

Just to clarify for the other readers: What you're using here is called simplify with side relations, and it's documented at ?simplify,siderels. The factor and the variable-order argument seem superfluous (in this particular case at least), and simplify automatically maps itself, so your code could be

simplify(
   evecA1[2],
   [rho*c^2/(gamma-1)*(1/rho)+(1/2)*u^2 = H]
);

The command algsubs is much overused. I find its results less predictable than its more-modern alternatives such as the above and subsindets (which won't work in this case).

@Mariusz Iwaniuk I don't think that you understand Joe's comment about the op in your Answer. For the particular example set or list given in the Question, the op(1 , ...) does nothing, and thus your code gives the correct result. But if a minor change were made to the example, such as  L:= {a = b[1], e = f[2]}, then that code would give an incorrect result.

@isifesai The Interpolation package is new to Maple 2018. With some small adjustment of Mariusz's code, you could replace it with CurveFitting:-ArrayInterpolation.

@Carl Love Using the process that I described, this is what I got for w[2](y,z) and w[3](y,z):

w[2](y,z);

-y*cos(z)*sin(z)/exp(y)

w[3](y,z);

(y^2*cos(z)^2*sin(z)*exp(y)+4*cos(z)^2*sin(z)*y*exp(y)-cos(z)^2*sin(z)*exp(y)-2*y*exp(y)*sin(z)+cos(z)^2*sin(z)+exp(y)*sin(z)-sin(z))/(2*(exp(y))^2)

@tomleslie Yes, good, vote up.

@dharr Oops, my thinking about this was backwards. When there are parameters the generic case is in general the defective case, and having a complete basis of eigenvectors is the exceptional case. Just think about A:= < 0, x; 0, 0 > for a moment. It's nondefective iff x = 0. If you do LinearAlgebra:-Eigenvectors(A) (without any other options or adjusting Normalizer), the returned matrix of "eigenvectors" contains a column of zeros. This column is not an eigenvector (the zero vector is never an eigenvector).

Nonetheless, my fundamental point that the number of eigenvectors depends on the parameters and requires case-wise analysis remains, and my title "Parameters may make it defective" still applies. I edited the Answer accordingly.

@tomleslie The same comment that I just made to Kitonum applies here as well. Is there something wrong with using Logic:-TruthTable(..., form= MOD2) for this? To me, it seems ideal for this plotting application.

@Kitonum While it's true that it's not, strictly speaking, necessary to use Logic for this, is there some good reason to not use it? The DataFrame output of Logic:-TruthTable is far more convenient to work with than your ad hoc sequences of true and false.

@Earl Thanks. The example, worksheet, and MathWorld link are sufficient.