@mmcdara 

For your point 1), I suppose that the element-wise application of is boils down to this kind of thing, where it matters whether the system allows for the second argument as a property.

is(3.000000, 3);

              true

is(sin(x)^2+cos(x)^2, 1);

              true

is(1, sin(x)^2+cos(x)^2);

Error, (in property/ConvertProperty) sin(x)^2+cos(x)^2 is an invalid property

Regarding you followup point 3), the element-wise multiplication of Arrays with the `.` command has been there since Maple 6, if I'm not mistaken. I have no problem with that syntax, which was available long before the element-wise tilde became available. If anything I'd say that I'm not a huge fan of the coercion from Array to Matrix/Vector as now done by LinearAlgebra commands.

A long time ago (Maple 6 time frame, say) there was a strong distinction between a Matrix as a linear mapping from one vector space to another and an Array as a more general kind of 2-dimensional collection of data.  I wouldn't be surprised if the rationale to allow coercion by LinearAlgebra commands were in part motivated by the wish not to surprise users (eg. Matlab users) coming into Maple. The system seemed more logically consistent to me when it was stricter in this regard. A somewhat related issue occurs for the distinction between row and column Vectors.

As for overload, you can read about it in the Help system. It's only my opinion but... they seem very nice and handy, up to the point that one has to debug them.

@Carl Love The DifferentialGeometry package has commands which change the prompt (as a semaphore of context).

@nm 

I have long advocated that help pages should quote option names and option values as if protectively and robustly coding for the most problematic cases. That includes quoting the global name where it may be necessary, where the global name is referenced using colon-dash. Eg.  ':-foo' .

I have a feeling that it's not done like that in the documentation for fear that it would lead to user confusion. (ie. Maple! So many kinds of quotes!) I hold the opposing view -- that properly, consistently, and defensively coding for the corner cases would lead to better understanding or at least acceptance of the safest practice.

nb. The fact that mint and maplemint may not emit any messages for a particular example procedure does not mean that it will compute as desired, or without error. Being "mint-clean" does not necessarily imply correct or error-free computation.

On a somewhat related note, I also think that help pages should utilize the colon-dash syntax when doing full reference to module-based package members, instead of using indexing.  A help page should reference LinearAlgebra:-Norm instead of the indexed form LinearAlgebra[Norm] , including in its Title and Description, as well as in cross-references in any See Also section. The indexed form is inferior in my opinions because it may need to be referenced safely as LinearAlgebra[':-Norm'] in order to guard against collision with possible local name Norm as well as to guard against collision with name Norm possibly being assigned at the higher level. There is some explanation on the help page with topic colondash .

Inductive reasoning is not a mechanism for mathematical proof, and is not mathematical induction. Something's very wrong if one ever mixes those up together in the same context.

A mathematician should not consider that "..it is sometimes very easy to believe induction is sufficient proof...", where the context qualifies that as inductive generalization or "inductive reasoning". 

@David1 

Download trigoac.mw

@tomleslie The worksheet was already there, a few hours before your last claim that it hadn't been uploaded. All you had to do was look. How hard can that be?

(This is the brusque way you often address people here.)

I should also mention the following mechanism (which I often reach for instead of unapply, because it has some more general uses):

Here, the Maple kernel replaces the formal parameter n (of the procedure) for the name n in the expression, when it forms the procedure body.

I also have the choice to declare local x in the template of the procedure body. That can be valuable. (These procedures bar will otherwise pick up any assigned value of x at the higher level from which bar gets called, typically resulting in a run-time error.)

Download subs_proc.mw

When you lprint the Array it does not show the entries whose value are zero (because that is the default value).

@taro 

Download cyl.mw

@Carl Love Good idea. I think I got confused about the question, and was thinking of function calls instead of stored structures.

You might have a look at these profiling mechanisms.

I'm not sure offhand what special support -- if any -- there might be for records or static methods of objects. I find it mostly useful for profiling my "Library level" interpreted procedure calls/usage. The CodeTools functionality is newer.

https://www.maplesoft.com/support/help/Maple/view.aspx?path=CodeTools/Profiling

https://www.maplesoft.com/support/help/Maple/view.aspx?path=exprofile

Do you mean that the Matrix appears as 2D Output, or was it inserted as 2D Input by using the Matrix Palette?

If the problem is with the Matrix as typeset 2D Input then does it work if you hit Enter and then try it on the output?

Why not upload a Worksheet or Document that exhibits the problem?

@vv That's nice. Here are a few more ways to accomplish those things -- and a few comments if I may add them -- using that generated f .

These following operator form calls work as they ought to.

int(f, 0..Pi, numeric);
evalf(Int(f, 0..Pi));
int(f, 0..evalf(Pi));

It's clearly a bug that evalf(Int(f(x), x=0..Pi)) does not work, while something weird like evalf(Int(''f(x)'', x=0..Pi)) does produce the float result.

It's unfortunate that D(f) has not yet been taught to return unevaluated, since the hook from evalf(D(...)) into fdiff is a useful syntax. Hopefully someone will fix that in D.

The first of these ideally would work as just evalf(D(f)(2)) . And the third of these ideally would not need the uneval quotes.

evalf(D(t->f(t))(2));
fdiff(f(x), x=2);
evalf(eval(diff('f'(x), x), x = 2));

Similarly, these would look nicer working with just D(f) instead of D(t->f(t)) .

plot([f, D(t->f(t))], 0 .. 10);
plot([f(x), D(t->f(t))(x)], x = 0 .. 10);

As a side note, these both compute without an error message.

fsolve(f, Pi/2..3*Pi/2);
fsolve(f(x), x=Pi/2..3*Pi/2);

And these first two calls succeed, but unfortunately the third emits an error message.

Optimization:-Maximize(f(x), x=0..Pi);
Optimization:-Maximize(t->f(t), 0..Pi);
Optimization:-Maximize(f, 0..Pi);

I suspect that some of these problematic cases relate to appliable modules more generally, and not just to Interpolation objects.

@AliahNiu The image shows {sin(x)}^(d-2) as part of the integrand, which is not valid syntax since the curly braces denote a set. That should be sin(x)^(d-2) .

Christopher2222, please upload the actual .mw file from which you are trying to retrieve the value associated with the "L1" label.

Then tell us exactly which platform you're using, eg. Windows 7 32bit , or Windows 10 64bit , etc.