@TomM Thanks. I can confirm that the phenomenon that you observed is duplicable in my Maple (2016.1). I'm still thinking about what to do about it, other than what you and Axel already mentioned. Certainly, the minor method is unacceptable for larger matrices.

Yes, an example is needed. I've generated several large (99 x 99) random examples without observing the phenomenon that you have.

@brian bovril Just change Data to L and it'll work. I decided to shorten the variable names at the last minute, and I forgot to change all occurences of Data.

@brian bovril Actually, FT and BP are initialisms but not acronyms, the distinction being whether one says the letters or pronounces it as a word. "Laser" and "NATO" are acronyms---the former common and the latter proper.

@Traruh Synred 

At the beginning of the worksheet, put this:

Pause:= proc()
     `Paused. To resume, click on Continue in this window.`;
     lprint(`Paused. To resume, click on Continue in debugger window.`);
     NULL;
end proc:
     
stopat(Pause, 3):

Then in the middle of the worksheet, any place that you want to pause, put

Pause();

The debugger window will pop up. Just ignore it (don't close it though) and go back to your worksheet. You will be able to scroll, but not to edit. When you are done reading, click on Continue in the debugger window. Then execution of the worksheet will continue.

@Christian Wolinski 

u[1](x) is both specfunc(u[1]) and specfunc(u). What is type(u[1](x), specfunc(anything, u)) in your version of Maple?

To extract the base name of a function, just keep applying op(0, ...) until you reach a symbol:

ExtractBase:= proc(X::{name,function})
local r:= X;
     while not r::symbol do r:= op(0,r) end do;
     r
end proc:

ExtractBase(f[1](x)(y));

     f

@shakuntala 

An example of multiple "lines" on the same odeplot:

plots:-odeplot(sol1, [[eta, f(eta)], [eta, diff(f(eta), eta)]]);

@Christian Wolinski 

No, not a Cartesian product. First, you need to be careful with using sets instead of lists because you can't determine the order of lists. {{1,3}, {1}} is interpretted as {{1}, {1,3}}. Then the {1} is matched with the {5}, and the {1,3} is matched with the {6}, so the result is

     {{1,5}, {1,3,6}}

Regarding your type question: I just anticipated this question a few minutes ago, and I updated my Reply above. Please reread it, especially the last paragraph.

P.S. And I just added more to the end to address the type of 'a =~ b' (with unevaluation quotes). Sorry, you were probably only asking about this unevaluated form, and I didn't realize that until now, instead giving a long answer about the evaluated possibilities of a =~ b.

Apparently Acer is in a more accomodating mood than I am today.

This cannot be considered a comparison of or a test of numeric integration speed because it's not necessarily true that the expressions being integrated are the same because the results of simplification might be different.

Your chain of simplification

expr1:=combine(expr0,power):
expr1:=combine(expr0,radical):
expr1:=simplify(expr1,LaguerreL):
expr1:=simplify(expr1,sqrt):

isn't a proper chain because you re-use expr0 in the second line.

In any experiment, you want to reduce the presence of potentially confounding factors. Student:-NumericalAnalysis is not needed for this computation, thus it's a potentially confounding factor, thus it should be removed.

You should do the forgets immediately before the time test. But, ideally, you should save the simplified expression to a temporary file, restart, gc(), read the expression from the file, then integrate. (The gc() updates the memory and time counters on the status bar; suprisingly, restart alone doesn't do this.) This process reduces the presence of potentially confounding factors.

@Christian Wolinski

The ~ comes after the operator; you show it as coming before.

Here's a brief introduction to elementwise operators intended for readers such as you who already have a high level of Maple knowledge. I'll address your "interpretted typewise" question after.

For an infix operator such as =, the ~ is interpreted as zip: A =~ B is the same as zip(`=`, A, B). For an unary prefix operator, the ~ is interpreted as map: f~(L) is the same as map(f, L). The operand(s) of a ~ operator can be

• container obejcts (list, set, table, rtable) of the same size,
• non-container objects that are treated as singetons, or
• some combination of the above.

So, for example, ~ can't be used to map over a polynomial because a polynomial isn't a container object. It is also not possible to treat a container object as a singleton. So, using an example from a recent Answer of mine,

{{1,3}, {1}} union~ {5}

(the intention being that {5} be treated as a singleton) doesn't work because the left and right operands are container objects of different sizes. This example must be recoded as

map(`union`, {{1,3}, {1}}, {5});

     {{1, 5}, {1, 3, 5}}

The ~ can be used a "super-zip" in the sense that it can take any number of arguments; for example,

f~([1,2], [3,4], 5, [6,7]);

     [f(1, 3, 5, 6), f(2, 4, 5, 7)]

The prefix form of an elementwise infix operator is as in this example: A =~ B is equivalent to `~`[`=`](A, B). So, there's a single "clearinghouse" procedure `~` with many possible indices. This is a nuisance when you need to overload these.

There are some details that I left out in the interest of time.

I'm not sure what you mean by "interpretted typewise". Do you mean What is the type of A =~ B? AFAIK, (builtin) elementwise operators are always evaluated, just as zip and map are always evaluated. So, A =~ B is not of type `=~`, if that's what you're asking. I suppose that one could construct an unevaluated elementwise operator by overloading `~`. So, if one were to do this, one could possibly have A =~ B being type specfunc(`~`[`=`]). I suppose that this could potentially be useful for a container object (a module with option object). I haven't tested to see to see if this is actually possible.

If you force the issue with unevaluation quotes, you get

type('A =~ B', specfunc(anything, `~`));

     true

type('A =~ B', specfunc(anything, `~`[`=`]));

     true

op(0, 'A =~ B');

     `~`[`=`]

In modern Maple, specfunc(anything, f) can be abbreviated to specfunc(f).

@Abdoulaye Your F is an expression, not a procedure, so F(t-2*Pi) and F(t) are nonsense. Unfortunately, Maple allows this nonsense without any complaint. Also, you forgot to add 2*Pi to the lower bounds of integration. Here's a corrected worksheet,

Download infnorm.mw

@Christian Wolinski There is no command OperandsTable. Is that something that you wrote but forgot to include above?

@Traruh Synred Sorry if I'm being repetitive about this, but I think that once you understand what a statement is, then this colon/semicolon stuff makes sense. Your code test:= proc() is not a statement---any proc() without a matching end is not syntactically correct. Other points that promote understanding of this ("semicolon" is interchangeable with "colon" throughout):

1. Semicolons do not terminate statements; just like in English, they separate statements. Also, they separate certain parts of a proc or module definition, like separating the local declarations from the body.
2. The empty statement is a statement.
3. Every proc and module has at least one statement, possibly empty.
4. A semicolon is allowed, but never required, at the end of a statement before end, else, elif, catch, od, or fi---there is no statement that it needs to be separated from.

@Traruh Synred wrote:

It seems an odd syntacs as I would have expected a dlimiter after the proc statement is defined and maple 15 puts them in in most cases even if you forget. [Emphasis added.]

Ah, but proc(...) is not a statement, nor is P:= proc(...) a statement. They are only the beginnings of statements; P:= proc(...) ... end proc is a statement. The fact that one usually begins a new line after a certain piece of code does not make it a statement.

@Markiyan Hirnyk Why did you choose the values for numpoints that you chose: 7 and 10? Is it just to make the computation faster? The left plot ends up using 39 points, and the right 23.