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

It seems to work for me, even in 2D Input in a Document and without encapsulating brackets around the procedure body.

Perhaps you could upload a Document that reproduces the problem.

Download if_operator_2dmath.mw

@dharr And he's also used the name I in a way that may have him confused.

Perhaps best for him would be to use some other name such as II instead. That's might make it more clear if the imaginary unit I appears in the result. (There are alternatives. But as it is the code looks confusing.)

@Bart Yes, using a value of 0.1 for the thickness makes the result from my suggestion to use subsindets look even better than the OP's suggestion to use value 0 does. I have edited my Answer accordingly, with attribution.

I have submitted various bug reports, on commands where thickness=0.1 is not allowed (but ought to be), and that the THICKNESS value 0.1 renders a thinner line that value 0 does. This kind of thing --- where Maple has the power but it's hidden -- needs to be fixed.