@mmcdara I am suggesting that you use AddBaseUnit to create units with arbitrary names such as Time, Length, Mass, etc., with corresponding dimensions time, length, mass, etc. Again, I have no experience with this, either mathematically or in Maple. But if you try it and run into trouble, I'm willing to help, as always.

@janhardo In this case, the series doesn't converge for all x, so you need to include an assuming clause:

S:= convert(ln(1+x), FPS);
value(S) assuming -1 < x, x <= 1;
             ln(1+x)

The interval of convergence of any power series is easily determined from the series itself. It is often smaller than the set of values that work in the corresponding function. In the real-number case, it is always an interval (possibly degenerate), never a more complicated set. In the complex-number case, it is always a circular disk (possibly degenerate), possibly including some or all of the disk's boundary.

@Gerd But if what you really want is the orbit, then the Orbit procedure is more efficient. It stops as soon as it detects the orbit rather than at an arbitrary spot like your 10. Also, it avoids raising the matrix to powers.

The first step is to use * instead of . for multiplication.

If you make those changes, I'll work further on your problem.

@Gerd Of course, the newer procedure cannot work in your Maple 18.

@Gerd  Just to give you a taste of the syntax updates over the years, the Orbit procedure could be shortened in Maple 2019 to

Orbit:= proc(L::Vector, M::Matrix, m::posint)
uses LA= LinearAlgebra, LAM= LinearAlgebra:-Modular;
local Mm:= LAM:-Mod(m, M, integer), L0:= LAM:-Mod(m, L, integer), L1:= LAM:-Copy(m,L0);
    [do L1 until LA:-Equal((L1:= LAM:-Multiply(m, Mm, L1)), L0)]   
end proc
:

Though the Maple 2018 syntax that I posted previously also continues to work.

@tomleslie You present an interesting example, but the issue has nothing to do with whether the sets are constructed with { } or with union. For example,

A:= Vector([1,2]): B:=  Vector([1,2]):
Q:= {A,B};
nops(Q);
             2

The key point is that mutable containers with different addresses are considered unequal, regardless of their contents. Set constructors do not consider unequal items to be duplicates.

@janhardo The command value will convert an FPS back to a standard function (if possible).

@nm When a name=range is given as the second argument, any reference to an indexed variable in the first argument used as the index variable of seq, add, or mul will manifest the bug:

restart:
seq(x[], x[]= 1..4):
x[];
              4

Also, the type assertion checker won't catch the altered value of x:

kernelopts(assertlevel=2):
proc() local x::nothing; add(x[], x[]= 1..4); x[] end proc();
             4

Please don't write an entire paragraph in the title box. Condense it to a one-line summary.

@Gerd I retrofitted both my Answer and the followup with the Orbit procedure so that I believe that they'll work in Maple 18, but I have no way to test that, so let me know.

And, yes, I do use a Maple version that's six years younger than yours.

@Gerd The header of your Question said Maple 2016. I will try to retrofit the code to Maple 18. I think that the relevant change is whether the seq command requires a second argument.

@tomleslie The problem is with Maple's definition of equals, not with its definition of set. Two vectors with equal elements are considered unequal because they have different memory addresses and could potentially become elementwise unequal. Note that I did not say that their equality cannot be determined; no, they are considered definitely unequal.

Let's say you have two boxes, one red and one green. Each box contains the numbers 1 and 2. The red box is delivered to 1 Any Street; the green to 2 Any Street. Are the boxes identical? Definitely not. Are they equal? It's debatable. Are they equivalent? Yes, assuming an appropriately defined equivalence relation. Those boxes are analogous to mutable containers. 

So, we see that the definition of equality (in Maple, in real life, in other software) is somewhat vaguely between identity and equivalence. 

@Gerd To me, it looks like my solution K1:= [seq]~(K) is much simpler than Tom's. Did it not work for you?

@tomleslie This shortcoming---that mutable containers (such as vectors) with equal elements are not automatically recognized as equal---is fundamental to the efficient operation of Maple, so I don't foresee it ever changing. The fundamental workaround is to convert the mutable containers to immutable ones, such as lists.