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

@tomleslie Vote up. The square brackets is the issue. If you'd gone further, you'd've seen that the plot works correctly with its five legends, but is, as you say, boring.

@Mac Dude What difference does that make?

@  Dr Venkat Subramanian

The issue is getting a good-looking (and, of course, accurate) plot. It is not necessary to know or to extract the points used internally by dsolve to do this. Yes, plot will by default use 201 points, unless its adaptive scheme decides that more are necessary. Each value of the independent variable chosen by plot is passed to the solution procedure(s) returned by dsolve. Those procedures may (and very likely do) use intermediate values of the independent variable to generate intermediate points. There is no need for those points to appear in the final output. Indeed, there are cases where using fewer points produces a smoother-looking plot. (Using plots:-implicitplot with the resolution option is a good way to generate an example of this.)

@Markiyan Hirnyk The issue is that the OP wants to generate a good-looking plot (no inaccurate sharp turns) without needing to select the points in an ad hoc way. To use the output= Array option, one needs to know a priori which values of the independent variable to use.

@shakuntala This back-and-forth with you not understanding is getting very frustrating, so you need to "come clean" about what exactly you're trying to do. Are you working on a course assignment? Are you working from a book? Please present the assignment or book problem in full.

What is your primary spoken language? If this question is part of a course, what is the language of instruction? If you're working from a book, what language is it written in?

@shakuntala In your originally posted code, you have the line blt:= 10. I assumed that this was still in effect. If it's not, then you must be solving a different ODE problem, in which case X21 and X11 wouldn't make sense either.

@acer If the OP is performing the NLPSolve inside a loop, as claimed, I'd more strongly recommend against using assign. It's still possible to use assign combined with some method of unassigning (either command unassign or assignments such as th:= 'th'), but that quickly turns into a mess. (Of course, I know that you know all the above; I just think that you may have missed the OP's "in a loop" issue.)

@shakuntala Yes, it's easy to combine any number of plots into one. One way is

plot([X11, X21], 0..blt);

The command plots:-display can be used in more-complicated cases:

plots:-display(
     plot(X11, 0..blt),
     plot(X21, 0..blt)
);

The inner plot commands can be any, as long as they all have the same dimension (two or three).

@Abdoulaye No, it doesn't help. There's a discontinuity in the link up of the two pieces at t = 11.72530194.