Assuming that they're column vectors, which is the default, do

plot([<X|Z>, <Y|Z>]);

Starting with your original L, do

convert((`[]`@parse)~(L), 'list');

There are two different types of places in Maple where information relevant to your session are stored in RAM. The most important of these are called kernels (or sometimes engines). There is usually one kernel per worksheet (*footnote1), although you can make other arrangements (many worksheets using one kernel or many kernels using one worksheet). Nearly all the commands that you literally type at a command prompt are directed at the kernel. So, this is the place where all the mathematical computations are done and which executes the Maple programming language.

The other type of place that stores information relevant to your session is the GUI or Graphical User Interface (*footnote 2). Nearly all commands executed with a mouse or arrow affect the GUI. It controls the way that things appear on your screen and things like statement labels. It controls copy-and-paste operations.

The ditto operators (%, %%, %%%) represent kernel memory. They are not equivalent to copy-and-paste. Anything on the right side of the arrow operator -> (or, equivalently, anything inside a procedure body) is not evaluated until the procedure is executed. So, x-> % is nearly meaningless. When a procedure is constructed by unapply, the arguments to unapply are first evaluated; so it'll work to use % there.

In your VectorCalculus example using labels, note Maple's response to your x-> (30). See that %id= <some long integer>? This refers to a specific vector (with that address), not a general vector that'll be constructed when the procedure is executed.

In summary, (1) don't use GUI features in procedure bodies (*footnote3), and (2) it's generally a bad practice to use ditto operators in procedure bodies, though it can work if done carefully.

*footnote1: I include command-line sessions as "worksheets".

*footnote2: I include the command-line interface as a possible GUI, though UI may be a more-appropriate initialism.

*footnote3: It is possible, even common, to control aspects of the GUI via plaintext commands in procedure bodies. I am referring to attempts to include non-plaintext GUI features in procedure bodies. That never works.

You could include the slope using the caption option within the plot command, like this

Explore(
   plot((a+2)*x+6, x= -5..5, view= -10..10, caption= typeset(`Slope `, a+2)), 
   parameters= [a= -4.0..3], initialvalues= [a= 1]
);

The first rule of numerical/computational linear algebra: Never invert a matrix of floats. That's a bit tongue-in-cheek, but you present a case-in-point.

1. The eigenvalue problem is still meaningful even if RS is singular, in which case only what you call the "direct method" will solve it.

2. Vv says that it's "almost singular". Hmm, I'd just outright say that it's singular with the nonzero value of the determinant being solely due to round-off error.

Suppose that the vector is V. Then do

select(type, op(2,V), posint=And(positive, Not(infinity)));

The result will be a set of equations. The left side of each equation will be an index, and the right side will be the corresponding entry.

To select all terms of poly which contain a name with literal subscript __b, use

select(hastype, poly, suffixed({unames()}, identical(__b)));

You may want to adjust that if you have cases where poly has only 1 term. Let me know.

Your inner while-loop condition is while A > B. Nothing inside that loop changes A or B. Therefore, the loop can't ever end.

By setting

printlevel:= 2:

at the start of your session, you will be able to see the results of the inner-loop computation.

When mod is presented with a polynomial, it acts on the coefficients only; the variables are considered transcendentals. This allows one to create fields of order p^k, k > 1, and even matrices over those fields. If you want to do modular arithmetic with symbolic variables that represent integers rather than transcendentals, then use irem instead of mod. For example,

irem(2*n+1, 3);

returns unevaluated.

You need the procedure at to act gracefully and return unevaluated when it is given symbolic (nonnumeric) arguments. This is similar to using the single unevaluation quotes, but more robust. The procedure will check for nonnumeric arguments and in that case return 'procname'(args). Change at to this:

at:= (x, yy)->
   `if`([args]::[realcons$2], `if`(x=0, Pi/2, arctan(yy/x) + `if`(x<0, Pi, 0)), 'procname'(args))
:

When solve does this, it puts assumptions on the variables. You can use the about command to find out what the assumptions are. Example:

solve(sin(x), allsolutions);

about(_Z1);

Originally _Z1, renamed _Z1~:
  is assumed to be: integer

Note that the tilde is not used in the about command.

These global variables do not have assumptions until you execute a solve command (or other command) that makes the assumptions.

For real x, the Taylor series for sin(x) is an alternating series, and for |x| < 1 (x in radians), the terms decrease in magnitude, approaching 0. The truncation error for such a series is less in magnitude than the magnitude of the first unused term. This is very easy to implement, like this:

ApproximateSine:= proc(deg::realcons, err::positive:= 0.00005)
local term:= evalf(deg*Pi/180.), x2:= term^2, S:= term, n;
   for n while abs(term) >= err do
      term:= -term*x2/2/n/(2*n+1);
      S:= S+term
   od;
   S
end proc:

#Make the table:
d:= <[$0..45]>:
S:= ApproximateSine~(d):
Err:= S - map[evalhf](sin, d*Pi/180.): 
interface(rtablesize= infinity):
< d | S | Err >;

Download Sine.mw
 

The name stem of an indexed name n can be extracted by op(0, n). Therefore, the set that you want can be constructed by map2(op, 0, U).

One thing that I see as a true new functionality is the ability to overload operators (such as `+`) and builtin procedures (such as member) (*footnote). In the expression A + B, when an operand is an object, then that object's module is searched for procedure `+`. Without the newer objects, you'd need to use with to overload `+`, which'd effectively limit you to only one overload of `+`. See sections 9.5 and 9.6 of the Maple Programming Guide.

(*footnote) Only a very limited set of builtin procedures can be overloaded by objects.

If you use evala instead simplify, then you'll get precisely the form that you propose. I don't know why simplify doesn't do it; I think that that should be considered a bug.