@dharr I just think of indets as a command that returns all substructures of a given type. As such, it is extremely useful. I always use a second argument. I don't think of it as having anything to do with indeterminates. The one-argument usage should be deprecated.

Note that you can solve an equation for exp(a*d) and you can assign a value to exp(a*d).

@dharr This is a nuisance, but constants such as Pi are also considered names. So, keeping with the OP's use of type assignable, it's safer to use

indets(eq[1], assignable(name));

or, doing all equations at once,

indets({entries(eq, nolist)}, assignable(name));

Any multigraph can be converted into an essentially equivalent simple graph, suitable for use with Maple's GraphTheory package, by adding vertices of degree two. The process is as follows: If two distinct vertices are connected by n edges, then place a new vertex in the middle of n-1 of those edges. If a vertex is connected to itself by n edges, place a new vertex in the middle of all n of those edges.

@Preben Alsholm 

Vote up. Your commands can be combined with zip, which is, I think, a somewhat unusual usage of zip:

plots:-spacecurve(
     zip(solve, [(x-2)/3 , (y-1)/4 , (z-3)/3] =~ t, [x,y,z]),
     t= -5..5, thickness= 3, color= red, axes= normal
);

I don't know the answer to your Question. This Reply is just to bemoan the fact that what you want was extremely easy in Classic. You just typed Ctrl-R and typed your math expression as if it were a Maple command. The Ctrl-R still works in Standard, but it seems to only allow trivial math expressions, not stuff like summations and integrals.

This is the Classic feature that I miss the most :-( 

@tomleslie I believe that what the OP wants is to have the plots take up more space on the screen---to actually be larger.

@Dina 

If you need to retain the original matrix, as in your situation, then in-place operation is not appropriate.

It seems like you're trying to implement Cramer's rule. Here's a procedure that I wrote for it:

CramersRule:= proc(
     A::Matrix(square),
     b::depends(
          And(
               Vector[column],
               satisfies(b-> if op(1,b)=op([1,1],A) then true else error "Size mismatch" fi)
          )
     )
)
uses LA= LinearAlgebra;
     try
          <seq(LA:-Determinant(<A[.., ..k-1] | b | A[.., k+1..]>), k= 1..op(1,b))> 
          /~ LA:-Determinant(A)
     catch "numeric exception: division by zero":
          print("No unique solution.")
     end try
end proc:

The expression which substitutes b for the kth column of A is <A[.., ..k-1] | b | A[.., k+1..]>. This is valid even for the first and last columns. This generalizes Kitonum's three examples into a single command.

@GoitaHass 

If works almost the same in Maple as in Matlab. You just need to append ~ to the operator to make it elementwise. Like this:

A -~ 5;

@tomleslie I didn't say that your original was ugly; I gave it a vote up. But since you said that it was "awkward" and "ugly", I thought that I'd show you an alternative.

Regarding the op(3.., S): There are several things to note about this:

• op(3.., S) returns NULL if S has two arguments. This is in contrast with op(3, S), which would generate an error.
• op(3.., S) transcribes not just the third argument (if it exists), but all subsequent arguments.
• There's nothing stopping a user from including extra arguments in an inert Sum, for whatever reason, even though they have no official meaning to Maple. Perhaps they're used as a sort of comment field. Presumably such a user would want the extra arguments retained in the transformed Sum. 
• Perhaps in the future meaningful extra arguments (such as options) will be added to sum, just as they've been added to int and Int. Including the op(3.., S) now means that this code will work then. Insulating code against potential future changes in the environment is a form of robustness.

@tomleslie You may find the following modification of your procedure more palatable. It doesn't use subsop. It builds a new sum from the components of the old rather than making substitutions in the old.

ShiftSum:= proc(S::specfunc({Sum,sum}), p::integer)
local ind:= op([2,1], S);
     op(0,S)(eval(op(1,S), ind= ind+p), ind= map(`-`, op([2,2], S), p), op(3.., S))
end proc:

@acer I don't think that it's a bug. I think that names that appear in procedure headers are always names, never evaluated.

@vv Brilliant!

For those who eschew verbose code, it can be condensed to

createModule2:= proc(A::Matrix(square))
uses LA= LinearAlgebra;
     module()
     export
          det:= subs('dim'= LA:-Dimension(A), (x::Matrix(dim))-> LA:-Determinant(x))
     ;
     end module
end proc;

@Christopher2222 If you want the closest fraction with a given denominator, then you'll need to use round instead of floor.

@Doug Meade Since the OP said "inch fraction" rather than "fraction", I took that to mean that the denominator had to be a power of two. It's traditional to use only dyadic fractions when specifying inches. You'll notice this in the size specifications for hardware (nuts, sockets, screws, etc.).

My procedure doesn't specify the number of bits for the numerator; it specifies the maximum number of bits to allow for the numerator, which is equivalent to specifying the maximum power of two to allow for the denominator, (the fractional part being always less than one).

@charlesforgy I agree with Stephen Forrest that the error is unlikely to be in the passing of the list. You mentioned "Maple's method of passing data structures by reference." I don't understand how this could make any difference for a list. The contents of the list are another matter. I'm suspicious about your b1, b2, ..., bn. What type are they? Are they something mutable like Vectors or tables? Are they names? If so, are they global or local names? Note that names created with ||, cat, or nprintf are always global.