Having all those individual elementwise operations seems overly complicated (and as seen, somewhat error prone), especially in 2D Input mode.

It's also less efficient, I suspect, since using it produces lots of collectible garbage Vectors unnecessarily.

Instead, you could simply construct a single operator that acts on scalars, and then apply that elementwise to your pair of Vectors.

Download Elementwise_ac.mw

note: I would often prefer a scalar operator (used as a single elementise operation) then a whack of visually confusing typeset elementwise operations in 2D Input, even if it were less efficient (and I suspect it sometimes isn't). Opinions may vary...

ps. Here you might also use zip(sm,V2,V1) instead of sm~(V2,V1) .

You can simply declare the name a as local to the procedure, without the type being part of that declaration. You don't have to add types to any local declarations. For example,

   proc(...)
      local a, b;
      a := Array(...);
      b := [...];
    ...
    end proc

The special type declaration of locals is only enforced (when the procedure gets subsequently called) if the assertion-level check is set high enough (which it is not, by default).

For the Description of the Help page for Topic procedure:

By default the value of kernelopts(assertlevel) is 0. So by default such types specified in local declarations are not checked. They can be present, whether checked or not. You have to issue kernelopts(assertlevel=2) to have them get checked when the procedure gets called (run).

The presence of the types in local declarations in your custom procedures is optional. Whether such types are checked is also optional (and can be enabled/disabled by command).

Does that make it clear?

You could check this over. (I don't know whether you have restrictions on a, z, x1, etc.)

Download someint.mw

You haven't described what general programmatic functionality you might be after, but here's a start by handling your given example (and allowing general expressions on either side of the equalities, not just those simple names).

You might have already noticed that the 2D Input that looks like a=b=c gets parsed as a=b and b=c , so below I follow that idea.

Download TS_multieq.mw

You could revise it to accept inequalities (and merge them when sensible). Or you could revise it to accept the kinds of relations as additional arguments, eg. `=`, `<=`. Then you might naturally support things like,   a = b >= c  and so on.

Two ways of constructing something that prints (ie. displays as 2D output) like you've requested are as follows:
  1) Using exports like mrow, mi, etc, of the Typesetting package.
  2) Using a specially constructed name that looks like compact calls to such functions, much like MathML. (This is sometimes called TypeMK in Maple.)
The Java GUI knows how to format both of those as nice 2D output. Both 1) and 2) are undocumented, but are close enough to MathML to figure out. Here's the earlier first example, done both ways.

Download TS_MK_multieq.mw

So for either of these approaches your task amounts to programmatically constructing these beasts.

I chose 1) for the implementation in my Answer, on the chance that that you might also to want be able more easily to parse the results to actual Maple expressions. It also makes it easier to typeset compound expressions for each side of the (in)equalities.

For 2) you might use the nprintf command, though it gets trickier to nicely handle compound expressions. For the simple first example of just names like a,b,c, it can be constructed programatically like so,

nprintf(`#mrow(mi(\"%a\"),mo("&equals;"),mi(\"%a\"),mo("&equals;"),mi(\"%a\"));`,  a, b, c);

An easy way to start figuring out some of this syntax is to enter some 2D Input, then right-click to convert it to so-callled Atomic Identifier (aka. a single name, using TypeMK), and then to lprint that. This can give you insight as to how it works.

Below I'm making the working precision within f (and whatever tolerance evalf(Int(...)) uses accordingly) relate to that of the top-level from which g gets called, with rounding. My purpose there is to avoid f inheriting the working precision raised internally by fsolve.

Download inverse_function_with_fsolve_ac.mw

Give that particular form of expression, you could try one of these,

   remove(depends,Expr,C);

   remove(has,Expr,C);

   eval(Expr,C=0);

These rely on the C[k] terms appearing in the way they do in your example.

One way involves using the select command.

L1 := [[1,1,1,1], [1,2,0,0], [0,0,0,0], [1,1,-2,0]]:

select(L->add(L)=0, L1);

        [[0, 0, 0, 0], [1, 1, -2, 0]]

That should work in Maple 2015 and later. In older versions you could do a similar thing as,

select(L->`+`(L[])=0, L1);

Are you saying that you'd like to configure a custom worksheet as your Start Page?

That is documented here.

You could use an empty Table, instead of the one you showed above.

The second case gets automatic simplification of the literal input 2*(x+2*y), but case 1 does not.

Note that automatic simplification occurs between parsing and initial evaluation.

Also, it cannot be prevented through use of unevaluation quotes (single right-ticks):

t^2*( '2*(x+2*y)' );

           2            
          t  (2 x + 4 y)

In your original case 1 the sum B is multiplied by t^2*A which is something that is not purely of type numeric, and that coefficient is not distributed across the sum.

When you alter your case 1 by introducing that eval call you are separating the steps, so that A*B is computed separately. In that case the sum term B gets multipled by the purely numeric value of A and that gets distributed across the sum.

Literal input is not necessarily going to produce the same result as substitution and evaluation after the fact.

note: A bit more on automatic simplification can be had in Section 3.4 "Unevaluated Expressions" of Chapter 3 of the Programming Guide, in the subsection "Evaluation and Automatic Simplification".

The following handles all the examples that you've supplied so far. That includes all the originally provided examples.

common_factor := proc(x::algebraic, ee::algebraic)
  local p, d := gcd(ee, x^frontend(degree,[ee,x]),'p');
  d * p;
end proc:

smthng.mw

Your call to sort(...) without options actually gets in the way.

restart;

expr := cos(x) - sin(x)/(x^2*y) + 3*x*y;

     cos(x)-sin(x)/x^2/y+3*x*y

simplify(expr, {sin(x)/cos(x)=tan(x)});

  -1/x^2/y*tan(x)*cos(x)+cos(x)+3*x*y

cos(x)*expand(%/cos(x));

  cos(x)*(-1/x^2/y*tan(x)+1+3/cos(x)*x*y)

sort(%, order=plex(x,y));

     cos(x)*(3/cos(x)*x*y-tan(x)/x^2/y+1)

I don't think that your use of ``() merits whatever benefits it might provide here (eg, if trying to yank out a numeric coefficient, say).

I suppose that you are getting the RootOf as result of some command, since otherwise you'd already have the expression x^2-1 at hand and this would all be unnecessary.

The first operand of the RootOf can be extracted using the op command. But the name x is not present in the RootOf.

A:= RootOf(x^2-1);

                               2
                 A := RootOf(_Z  - 1)

op(1,A);

                          2
                        _Z  - 1

This works for some pages, though it is rather roundabout. But it can be handier for long Topics.

1) In the open Help, use the menubar icon with tooltip, "Open the current help page in a worksheet window"

2) In that opened worksheet, use the menubar item, File -> Document Properties

3) Copy the entry for the Topic Property

4) Paste that in to the right-click Convert To -> Hyperlink popup.

@Amir_Maple Different approaches to performing the integration can result in different values for the constant term. (As mentioned, the particular value of some constant term does not make the result invalid.)

poly_int_example.mw

From your description of your display problems I suspect that your session has been accidentally set to use prettyprint level 0 for output.

You can test that using the following command,

   interface(prettyprint);

which should not be executed in the same paragraph or execution group as an restart.

If that is the problem then you may fix it as follows:

a) Execute the command (not directly by any restart),
    interface(prettyprint=3):

b) In the GUI go to the menubar item Tools->Options->Display
    and ensure that the combo-box item "Output display" is set
    to "2-D Math Notation"

c) Press the "Apply Globally" button.  Then close the Maple GUI
    altogether, relaunch, and test it.

This may also help with the "Typesetting" artefacts you showed elsewhere.