B is the constant term in the series.  Thus it is the limit of your expression as sigma -> 0. 

That does work, but it is inefficient, because the whole list must be recreated to add one element.  This may begin to get significant when the number of elements gets into the thousands.  For example:

> ti:= time():
 A:= <1>:
 for i from 2 to 30000 do A(i):= i end do:
 time()-ti;

     .032

> ti:= time():
 L:= [1]:
 for i from 2 to 30000 do L:= [op(L),i] end do:
 time()-ti;

    10.967

Building an Array of size 30000 by adding one element at a time took only .032 seconds on my machine.  The same thing with a list took 10.967 seconds.

That does work, but it is inefficient, because the whole list must be recreated to add one element.  This may begin to get significant when the number of elements gets into the thousands.  For example:

> ti:= time():
 A:= <1>:
 for i from 2 to 30000 do A(i):= i end do:
 time()-ti;

     .032

> ti:= time():
 L:= [1]:
 for i from 2 to 30000 do L:= [op(L),i] end do:
 time()-ti;

    10.967

Building an Array of size 30000 by adding one element at a time took only .032 seconds on my machine.  The same thing with a list took 10.967 seconds.

The limit of what expression?  And why would you want to use l'Hopital's Rule?

Integers are summed automatically, so you need to change them to names if you want to make them inert.  You could try

> add(convert(i,name),i=1..5);

`1`+`2`+`3`+`4`+`5`

> map(parse, %);

15

Integers are summed automatically, so you need to change them to names if you want to make them inert.  You could try

> add(convert(i,name),i=1..5);

`1`+`2`+`3`+`4`+`5`

> map(parse, %);

15

The point being, I think, that if you convert a table with only integer indices to a list, the entries of the list are in the same order as the indices.  But in gepo's original code, one index of the table will be the name cnt, and then the order of the entries of the list is essentially random.

The point being, I think, that if you convert a table with only integer indices to a list, the entries of the list are in the same order as the indices.  But in gepo's original code, one index of the table will be the name cnt, and then the order of the entries of the list is essentially random.

You really need to be more specific.  Are you talking about numerical or symbolic solutions?   In what way are the results changing?

You really need to be more specific.  Are you talking about numerical or symbolic solutions?   In what way are the results changing?

|| (or cat) is primarily for concatenating names or strings.  It will also work if the second argument is an integer.  But it will not work for arbitrary expressions.  One way to handle those is to use printf.  Thus:

> eq := 5+3*x=0:
   x:=solve(eq,x):
   printf("x is %a\n", x);

To cause full evaluation inside a procedure, you can use eval. 

For example:

> f:=proc()   x:='y': y:=3;  eval(x) end proc:

You have not made any assignments, just created a sequence of equations.  Try

> assign(seq(DeltaX[a] = A[a+1,1] - A[a+1,3], a = 0..89));

You have not made any assignments, just created a sequence of equations.  Try

> assign(seq(DeltaX[a] = A[a+1,1] - A[a+1,3], a = 0..89));

My code works in Maple 13 Standard, but not Classic: in Classic, pointplot  doesn't allow a list of colours.  This is a bug.  Leave out the colour option (or change to colour=red) and it will work.

In your example, you're getting one point per frame because that's what you gave pointplot: c[i] is just one point.   You might try

display(seq(pointplot(c[1..i]),i=1..nops(c)), insequence=true);