@mmcdara Why do you consider that non-numeric indexing won't work?

And inside a procedure, you only need to declare the base-name theta as local.

Download diff_indexed_name.mw

@q41b3 The name P was already used, so some other name(s) are needed to which to assign the constructed matrices. You could also use a new base-name such as, say, Pmat.

You don't necessarily need to use concatenation to obtain the new names to which to assign the matrices. You could also using indexing on that base-name. Eg, Pmat[0]:=P and then in the loop Pmat[n] := evalm(Pmat[n-1] &* P[0])

And, no, you don't necessarily need to create/declare a structure in advance, to hold those Pmat[n] matrices. If you don't then Maple will implicitly create Pmat as a table (into which you can index). But if you prefer you could also create an Pmat:=Array(1..10) in advance.  The table structure is handy because you don't need to assign Pmat:=table([]) in advance (though you could) and its size is not fixed.

Using concatenation to construct the names isn't very elegant, in my opinion.

If you put the code into a procedure then using Pmat as a table or Array is convenient because you only have to declare the one local Pmat.

Here is the code using the more modern (captilized) Matrix instead of the deprecated (lowercase) matrix. You can notice that evalm is not required for arithmetic, and it prints directly. And matrix-matrix multiplcation is now done using the noncommutative dot (ie, . ).

I have also done this using 1D Maple notation (plaintext input) rather than marked-up 2D Input. I find it easier to edit, and unlike 2D Input it is WYSIWYG. It can be set as a global preference for new Worksheets under Tools->Options from the main menubar.

Download TransitionMatix_ac_Matrix.mw

@q41b3 

When you type else if you are doing two things with two otherwise unrelated key words:
1) You are starting an else clause in the current if..end if (of which there can only be one)
2) You are then starting a new, deeper level if..end if .

Your original went wrong because it started several nested/deeper if statements that lacked their corresponding end if bits. But even with those included there would still be another problem of trying to put multiple else clauses on the outermost if..end if. See the last attempted example below.

Perhaps the following will make it clear. The use of white-space and indentation is there to try and make it easier to understand.

Download elif.mw

@tomleslie Isn't that what my answer already did above (except for the highly trivial aspect of making T a parameter of an additional layer of encapsulating procedure)?

It looks like what the OP may be after, judging by his picture.

Given the disparity between the OP's original odeplot call and his posted picture, I'd suggest that understandability trumps maximal computational efficiency on a first run. (Things like maximal efficiency, adaptive plotting vs fixed mesh, ease of specifying which curves are included, etc, are additional considerations.)

At present these is no direct option of the Tabulate command to control the font size for either text or math.

If I recall correctly the font used for numeric entries (data) should match the worksheet's "2D Input" style, while the row and column headers should match the worksheet's "Text" style. You can see the main menubar's Format->Styles to check your worksheet's defaults for those.

When you simply print the DataFrame in the usual way then what you see is displayed in the "2D Output" style.

Can I ask, which look too big for you: the row/column headers or the data entries? What Operating System and Maple version are you using?

Are you interested in a solution which would allow you to customize the Tabulate entries individually cell-by-cell, or would you be ok with a solution that only let you put a blanket adjustment over all data entries and another for all row/column headers?

Would you be interested in a procedure that get's what you need, but only handles DataFrames and not other structures, including those with math and plots in them? (It's slightly easier to write one for your use now, then it is for me to come up with an edit to Tabulate itself). Or perhaps you wouldn't be interested in any customized alternative right now, because it's be awkward to re-use it?

@mugwort Perhaps you might consider uploading your actual problems, in worksheets, when you first post future Questions.

@Carl Love Yes, a dedicated tridiagonal solver can beat a general band solver, as you've nicely shown. And even more so if the band solver is not set up for convenient re-use of pre-factorization.

I have written solvers (and re-usable prefactorization based solvers) for both band and tridiagonal myself; as you've shown it is reasonably straightforward. The more specialized solver outperforms the more general, and the prefactorized usage does better still.

So, if one can quickly write a numeric solver that handles a specific Matrix shape better, why doesn't Maple cover it? That is a sensible and interesting question, I think. I think that -- leaving aside wider issues of priorities -- the answer can include this: Writing the solver can sometines be the least involved part of the software development, with coordinated integration into the product requiring the larger part of time resources.

@Rouben Rostamian  

[edit] I realize that your worksheet may be primarily expository, and it is very nice btw. I add these comments below merely as followup to Carl's remarks. I would not be surprised is overhead of creation of Matrix A, etc, may dominate at this stage of the work. And that's fine.[/edit]

Maple has a band (float) solver that is fast here.  At sizes m=n=50 you may not be able to distinguish the performance differences. But as the problem size increases the band solver's performance superiority comes through.

At large enough Matrix size n the scheme of precomputing the full rectangular LU decomposition leads over precomputing the inverse. Worst of all, naturally, is doing the full rectangular LU+back/forward solving for each rhs V.

(Maple doesn't offer precomputing the P,LU for a band storage, in part because it needs a structure larger than input AT and things get a bit awkward functionality-wise. And it's a performance bug that MatrixInverse doesn't utilize the band solver.)

But there is an additional risk to multiplying by the inverse, in that it may not be as numerically robust.

In summary, calling LinearSolve with the float[8] band storage Matrix A is likely best for performance and robustness (unless you write your own dedicated, optimized solver for this tridiagonal case, of course).

You can utilize infolevel[LinearAlgebra] to see what's being called externally. I didn't look at the scheme for performance considerations/optimizations (inplace stuff, etc).

You can play with the N=n and maxiter=m in this attachment. (The NAG function names in the userinfo message are actually their LAPACK equivalents in the Intel MKL these days.)

band_LU.mw

@tomleslie It was not possible for many years, and it was introduced to 1D before 2D, and Section 6.9 of the Programming Guide still says the body must be a single expression.

@tomleslie Cutting and pasting your example in as 2D Input, it works as the body of an operator.

Download 2dmath_elif_operator.mw

I only tried Maple 2019.0, Maple 2018.2, and Maple 2016.2.

I also works if I type it all on a single line.

@tomleslie I have no idea what you're trying to state, sorry.

You made a claim about operators and requiring `if`(...) form which is not correct.

Also, you made it sound very much like the OP's problem was because he was not using `if`(..) form, and that is not true.

@abecke12 Many users of Maple make these two changes as global preferences in the GUI:

1. File->New shows a new Worksheet rather than a Document.

2. Input notation is 1D Maple Notation (plaintext), rather 2D Input.

Both can be set and saved globally for all future sessions under Tools->Options.

Output still gets marked up and displays in 2D Math.  But the input code is WYSIWYG. And Worksheet editing and navigation are much, much better than for Document.

And the parsing has much, much fewer irritations, issues, and bugs.

@abecke12 Using that much 2D Input can really slow down the parsing of the worksheet, especially (but not restricted to cases) when it thinks there's an issue.

I'm amazed whenever I see anyone willing to wait for several seconds or even longer for parsing that is almost immediate in 1D Maple Notation.

@tomleslie Your claim about operator definitions requiring the form `if`(...) is incorrect. Not even for 2D Math.

It just happens to fix this particular example (as Carl had noted) because some weird bug is occuring with the 2D Input parsing of the wider procedure that encompasses the operator. The GUI displays a red boxed message that wrongly indicates a problem point.

@abecke12 If I just delete some lines from near the bottom of the procedure defn (almost at random) then it parses without that error. So it's possible that it's a 2D Math parsing bug.