The very first line of the Description of the Help page for Topic error refers to it as the "error statement".

There are other kinds of statement, for example the selection (conditional) statement and the repetition statement. Those also do not require brackets in that they are not called like functions (though delimiting brackets to establish grouping or operator precedence may be used).

There is also an older (deprecated) ERROR function, which is called with brackets denoting the functional application.

So I disagree with your claims, citing the above as evidence. You don't call error with a functional application because it is offered as a statement rather than a functional call. And there are indeed other kinds of statements which also can be made without a functional call, and which also do not always require bracketing (either as delimiters or to denote a functional call).

[edit] You wrote that the syntax for error is, "...different from all other Maple functions". That's because error is not called like a function, so it doesn't make sense to compare it with "other" functions. The brackets in your second example don't change the nature of the statement.

Perhaps it would help to think of error as a language keyword.

You could consider the error statement and the (old, deprecated) ERROR function along with the return statement and the (old, deprecated) RETURN function.

You can save a few characters with,

    ['A'[..,i]$i=1..4]

If you want a re-usable procedure (for Matrices of general size) then you can do as follows (this too is shorter than using seq, and so is terser than Kitonum's suggestion).

Download cols_list_proc.mw

You wrote, "...i assign stepsize to have accurate results". That is untrue -- a small fixed step-size does not -- in itself -- guarantee better accuracy.

If you are going to do something as forcing and, in my opinion, unjustified as fix a very small step-size then you may well have to raise the limit on functional evaluations.

Your call to plot of GAM(tau) suppresses the warnings about exceeding the maxfun value. You could do better here to instead use the plots:-odeplot command, which as seen below would have informed you through a warning of the problem stemming from your forced small step-size, even without raising infolevel.

But even calling GAM for tau values further toward the right end-point can show you that problem. It makes sense to test your solution, when you encounter difficulties.

Download dsolve_stepsize.mw

note: There are other reasons to use plots:-odeplot. It contains some extra smarts to try and use independent variable values dictated in part by the solver, as opposed to just calling plot and having its adaptive algorithm try and pepper the space as it wants. Just my opinion.

You have mentioned doing the "operation in reverse by hand". If that entails applying tan both sides of the equation (after isolating) then note that is not generally valid.

It does not following that A=B just because tan(A)=tan(B).

Is this the kind of thing you are trying to accomplish?

Note that (the way the conditional if..then inside your procedure lambda22sol is set up), if you call procedure lambda22sol a second time without unassigning __old_a then it will return NULL. I suspect that is why you got that error message, because you were calling it twice and so the middle column of matrix1 from the call lambda22sol(0.9) was NULL.

Download lambda22sol.mw

Download int_ex.mw

In a sense, that could be broken down into steps:  int_ex2.mw
There I replaced the numbers 2018 and 2019 by symbolic names, temporarily, to prevent awkward expansion. The following also works directly:

simplify(int(1/(x-1)+sum((k+1)*x^k,k=0..N)
                     /sum(x^k,k=0..N+1),x));

               ln(x^(N+2)-1)

There is a form, on the Software Change Request page (linked from the Mapleprimes top "More" tab).

(Rewritten question is now asked here.)

The axis mode is part of the generated plot structure (set altogether as the value property of the embedded component), and not a property of the embedded component.

You can add axis[2]=[mode=log] to the dataplot command.

>  restart; >  DetAnalysisNx2:=[seq(0..2,0.1)]: >  DetAnalysisDeterm2:=map(x->exp(x^2),DetAnalysisNx2): >  DocumentTools:-SetProperty("DeterminantenRaumPlot1",                            value,                            dataplot(DetAnalysisNx2, DetAnalysisDeterm2)); >  DocumentTools:-SetProperty("DeterminantenRaumPlot1",                            value,                            dataplot(DetAnalysisNx2,DetAnalysisDeterm2,                                     axis[2]=[mode=log]));

Download log_mode.mw

Download trig_phaseamp.mw

Yes, it can be done using plottools:-transform as follows,

f,g := 1,min(3,1/x):
P:=plot(f-g,x=0..maximize(1/y,y=1..3),filled):
plottools:-transform(unapply([x,y+g],[x,y]))(P);

Of course, you might be able to see that the upper end-point of the x-range is just 1, without having to compute that from maximize(1/y,y=1..3).

And so you might also write down either of these, directly. They each produce a plot with the region shaded.

plottools:-transform((x,y)->[x,y+min(3,1/x)])(plot(1-min(3,1/x),x=0..1,filled));

plottools:-transform((x,y)->[x,y+1])(plot(min(3,1/x)-1,x=0..1,filled));

You can refer to the global names as :-J and :-F, in order to avoid collision with the locals of the same names.

You can furthermore quote those global name references with uneval quotes, so as to protect against the case of their having been assigned values.

Download JordanForm_proc.mw

ps. You could sensibly quote the keyword option 'output' as well, on similar grounds.

It's not your fault; there is a bug in the case of filledregions, a specified non-default number of contours, and the new legend mechanism.

I am supposing that you want the specified number of contours (20) as in the first plot below, but the visual look of the thicker color bars in the second plot below.

(I may be able to figure out a hot fix for the procedure, a bit later today...)

Download filled_cont_legend_bug.mw

You are getting bitten by premature evaluation of the call f(x).

The error would occur even if you tried just to compute this,

    f(x);

Either use the functional calling sequence of the plot command, or pass 'f(x)' quoted so as to delay evaluation, or edit procedure f so that it returns unevaluated for nonnumeric x (I haven't done that last one).

Download Heck_15.5.mw

If you click on the magenta error message as displayed in the Maple GUI (and if Maple is set to find your web-browser) then it should take you to this related Error Guide page.

[edit] On page 426 of the Heck text (as found by Google) I see the example in question as computing the problematic plot using the functional form, ie.
   b := plot(f, 0..4*Pi, filled=true, color=white):
in the 3rd edition (2003). That happens to coincide with the first way I gave above. It seems as if you have made a mistake, while editing his example.

Change

   Pi(d/2)

to,

   Pi*(d/2)

The former is a functional application of the name Pi to the argument d/2. Presumably you want the multiplication. instead.

In 2D Input you could also use a space before the bracket, to denote so-called implicit multiplication. I find that hard to distinguish, visually.

You can insert the explicit multiplication sign whether in 1D or 2D input mode, and I think doing so is a good idea.
 

Download multiplication_syntax.mw

It is documented in the Help page with topic coloncolon .