@C_R Your syntax,

E := t -> Mt(t);
diffeq := D(C)(t) = E;

is muddled. Utilizing the ensuing "solution" from dsolve in odeplot will not actually make any calls to E. You'd get similar invalid results with, say,

Q := z->0:
diffeq2 := D(C)(t) = Q;

Also, could you please show how your remarks about derivatives of a linear interpolant come into play with this particular result from LinearInterpolation? (We know that we could simply get by with 3*t instead, but that's quite another issue.) How does your claim explicitly come into play with this returned Interpolation object? Or perhaps you were writing more generally, say of piecewise linear examples where the derivative might agree in limit on only one side of each data point?

@Rouben Rostamian  That would get get it down to 3 times. His code also called his procedure three times unnecessarily.

It seems to me that the OP is trying to learn how to code better in Maple.

@Rouben Rostamian  If only those changes are made to the original code then it will (unnecessarily) call operator fun nine times with the same arguments.

Those multiple occurrences of `>` within a single execution group have little to no effect.

They are mostly just artfefacts of how multiple execution groups might have been joined (with the F4 key, say).

The name t in your passed equations DV1,DV2 is not the same as the local t declared and used in your procedure.

ps. I changed both this and your previous query from a Post to a Question. Could you please submit future queries as Questions rather than Posts?

If you're going to submit further queries on this same topic then could you please either 1) use the Branch to split them off the earlier one (which automatically inserts cross-reference links, or 2) just add the close followup as Comment/Reply in the earlier thread?

@C_R 

The first part of this explains why your earlier approach did not work. Ie. why the running value of loop index i doesn't get put into the bodies of the operators constructed by,
    x -> `^`(x,i)

When you utilize unapply within a loop then the running value of i gets picked up because of what the first argument (to unapply) evaluates to.

Download proc_notes_1.mw

Pardon me if I also try to explain it slightly differently, using a loop:

Download proc_notes_2.mw

@mmcdara

First, please note that the first sentence of my Answer is specifically about the fact that this simpler approach is possible. As it stands, of course, the extra locals and assignments are wholly unnecessary.

Second, I supposed that he has some further purpose, as yet unstated by him. I supposed that perhaps his actual intention is to have his procedure manipulate its parameters (arguments) DVA,RV1A,RV2A and then assign the modified ones to locals DV,RV1,RV2 and utilize those in the plotting.

Third, his code already had lines that appeared to be possibly for such assignment.

So I went along with that aspect of what he already had.

[edit] At first I wondered whether he could instead use DEplot. I didn't notice that the symbolic solution makes the left end-point easier to deal with. I think I see better now why he'd made the custom procedure. (I don't know whether he'll also want to handle odes without an explicit symbolic solution...)

I've changed your Post into a Question.

Please put any followup queries on this here, instead of spawning wholly separate new Question threads on it.

Duplicate Question threads get flagged as such and may be deleted.

It seems that this dies when attempting to convert to parfrac.

@sand15

It seems that OuterProductMatrix may be measurably faster than KroneckerProduct in the case of symbolic entries. For float[8] Vectors it's much closer.

nb. Switching the other of the arguments seems better than transposing either result.

The `.` variant ends up calling OuterProductMatrix, with a tiny extra bit of overhead to get there (and less flexibility w.r.t. transposing).

@Carl Love It appears to work in Maple 2019.2.1 onwards.

@Carl Love Indeed.

In my Answer I had mentioned that  evala(simplify(expr))  would produce -2/7 back in Maple 2022.2.

As Austin mentions, in Maple 2024.0  simplify(expr)  no longer throws an error (or crash).

I have deleted a duplicate of this Question's thread.

@nm A short variant on your suggestion,

   sort(X,key=(u->parse(String(u)[2..])));