You might be interested in a Maple application I put together some years ago, dealing with SIR models: An Epidemic Model (for Influenza or Zombies)https://www.maplesoft.com/applications/view.aspx?SID=127836

@Markiyan Hirnyk It depends on what you mean by "duplicates".  Two members of a set can't have the same internal Maple representation.  They could, however, be equal mathematically with different representations.  Things are more complicated when rtables (Arrays, Vectors, etc.) are involved: two of these, created separately, would be treated as different in terms of a set even though they are mathematically the same.  For example, try:

> A := <1,2>: B:= <1,2>: {A,B};

I think you'll need to provide us with a lot more details, and maybe a screen-shot, before the problem can be diagnosed.

@vv 

Another possibility, with a finite sum such as this one, is to use add rather than sum.  This has special evaluation rules such that it doesn't matter if the index variable has been assigned a value. In general, sum is for symbolic summation while add is for adding an explicit finite sequence of values.

f:= n -> add(i^3, i=1..n);

The gfun package is useful for finding generating functions and linear recurrences satisfied by sequences, given the first few terms.  In order for it to work for your first example, you would actually need a couple more terms.

with(gfun):

A:= [100, 101, 97, 106, 90, 115, 79, 128, 64, 145, 45]:

guessgf(A, x);

listtorec(A, a(n));

rsolve(%[1], a(n));

Another useful resource is the On-Line Encyclopedia of Integer Sequences, which is a searchable database of over a quarter-million such sequences (more being added every day).  This particular one is not there, but your second example is: a search for  0, 1, 8, 11, 69, 88 finds sequence A000787.

Although the OEIS does not have the first sequence, it does have a "super-seeker" that can relate it to sequences that it does have.  Email to  superseeker@oeis.org with no subject and a line

lookup   100 101 97 106 90 115 79

will (after a few minutes) get a return email describing many sequences related to this one by various transformations.

@mcouture  Yes, they work!  Thanks.

@Dr. Venkat Subramanian

This is rather strange.  If I restart and read the .m file (in the same Maple session), everything works OK.  However, if I try it in a new Maple session, or a new worksheet (with a new kernel), I get a kernel error.

The same happens for procedures compiled with Compiler:-Compile.
It does seem that something in the compiled procedure is specific to the particular Maple session and kernel. 

@Dr. Venkat Subramanian

The work-around seems to be to save your procedure in Maple internal format as a ".m" file rather than ".mpl" which is ordinary text.  Thus, after defining sol:

> save sol, "dsolvesol.m";

> restart;
> read "dsolvesol.m";
> sol('parameters'=[1,1]);

> sol(1);

Warning, cannot evaluate the solution further right of .63313380, event #1 triggered a halt  

[t = .633133804626753, y(t) = .500000000000000, z(t) = .361834982920762]
 

(which is the same as I get with the initial definition without save, restart and read)

Yes, this seems to be a bug.  I'll submit an SCR.  I don't think this bug has to do with the compile option per se: if I remove that option, the error still occurs.  If I set the parameter values before saving, I can read the procedure back from the .mpl file and run it with the saved parameter values, but it is impossible to change the parameter values.

testeq seems to have improved considerably over previous releases, where there were lots of false positives: e.g. testeq(exp(2 * Pi * I * x)=1) returned true.  Now it is much more cautious.  However, this means it will return FAIL in many cases where the expression may or may not be zero.  For example, it doesn't recognize the following as 0, although it really is:

> testeq(-1-2*cos((8/83)*Pi)-2*cos((10/83)*Pi)+2*cos((9/83)*Pi)+2*cos((5/83)*Pi)+2*cos((7/83)*Pi)-2*cos((2/83)*Pi)+2*cos((1/83)*Pi)-2*cos((38/83)*Pi)+2*cos((41/83)*Pi)-2*cos((40/83)*Pi)-2*cos((6/83)*Pi)-2*cos((4/83)*Pi)-2*cos((36/83)*Pi)-2*cos((32/83)*Pi)-2*cos((34/83)*Pi)-2*cos((30/83)*Pi)-2*cos((26/83)*Pi)-2*cos((28/83)*Pi)-2*cos((24/83)*Pi)+2*cos((31/83)*Pi)+2*cos((33/83)*Pi)+2*cos((29/83)*Pi)+2*cos((37/83)*Pi)+2*cos((35/83)*Pi)+2*cos((39/83)*Pi)-2*cos((22/83)*Pi)-2*cos((18/83)*Pi)-2*cos((20/83)*Pi)-2*cos((14/83)*Pi)-2*cos((16/83)*Pi)-2*cos((12/83)*Pi)+2*cos((27/83)*Pi)+2*cos((25/83)*Pi)+2*cos((23/83)*Pi)+2*cos((13/83)*Pi)+2*cos((15/83)*Pi)+2*cos((11/83)*Pi)+2*cos((3/83)*Pi)+2*cos((19/83)*Pi)+2*cos((21/83)*Pi)+2*cos((17/83)*Pi));

   FAIL

And so after Testzero:=testeq, Maple will happily invert a matrix whose determinant is that expression.

@vv 

The way I got it was:

R:= Array(-99^2 .. 99^2):
for a from -99 to 99 do
  for b from -99 to 99 do
    p:= a*b;
    R[p]:= R[p] + 1
od od:
add(R[p]^2/199^4, p=-99^2..99^2);

@Carl Love
 

A random square matrix whose entries have a continuous distribution has probability 0 of being singular.  However, the output of RandomMatrix (with default parameters) has entries that are integers from -99 to 99.  The probability of the result being singular is nonzero.  The actual value of this probability, I suspect, is rather hard to compute unless the matrix is quite small.  For the 2 x 2 case it is or approximately 0.0003580072476.

It's worth mentioning as a  general strategy for this type of question: the help system contains "updates" pages for each release of Maple, going way back, and these usually mention new packages and commands when they are first introduced.  Thus one of the Search Results for the help query ?applyrule is "updates,R5,symbolic", which is the help page "Improved Symbolics in Maple V Release 5" that mentions applyrule as a new command.

It also works with the _EnvExplicit environment variable set to true.

@Carl Love  Good point.  The only mentions of explicit options I could find in the documentation were in connection with roots of polynomials being expressed using radicals and with dsolve.

@Rouben Rostamian  That's a bad bug!  Dot products of vector fields with Nabla use DirectionalDiff, which normalizes the direction, but that's not what you want here.  So dot product of any non-unit vector field with Nabla will be wrong.  I'll report this bug.

A work-around is to replace V.Nabla with w -> V . Gradient(w).  Thus

> with(VectorCalculus):
   SetCoordinates(cartesian[x,y,z]):
   V:= VectorField(< seq(v[i](x,y,z,t),i=1..3)>);
   NavierStokes:= rho*(diff(V,t) + (w -> V . Gradient(w))~(V)) =        
        - Gradient(p(x,y,z,t)) + mu*Laplacian~(V) + VectorField(< seq(f[i](x,y,z,t),i=1..3)>);