@Carl Love 

Yes, sadly VerifyTools is still undocumented, I wonder why (the copyright of the verification procedures says 1999). I have not had time yet to explore it thoroughly, but the same as the documented part of the verify facility shows that it was inspired after type, the overall design of its extension mechanism looks roughly similar to that of TypeTools. In particular it exports these procedures:

[VerifyTools:-Verify, VerifyTools:-AddVerification, VerifyTools:-RemoveVerification, 
VerifyTools:-HasVerification, VerifyTools:-GetVerification, 
VerifyTools:-GetVerifications, VerifyTools:-IsFalse, VerifyTools:-IsFail]

And the private table VerifyTools:-VerifyTab shows interesting pieces of code for verification procedures, some of them useful but undocumented also.

@Carl Love 

This thread shows that the subject of mutable and immutable objects is still subdocumented. The chapter 4 of the Programming Guide has been an improvement, but it is not yet comprenhensive enough. E.g. where is the complete list of mutable data structures?

Equality by memory address is a check at the syntactic level, and this is OK for low level programming. But at the mathematical (or semantic) level, an isolation of those details is needed. The verify facility ( check ?verify ) is quite useful for this purpose (though little used). For instance:

> verify(table([0=0]),table([0=0]),table);
                                      true
> verify(Vector([3, 3])-Vector([3, 3]),Vector([0, 0]),Vector);
                                      true

Moreover it is quite flexible (check ?verify,structured ) and extensible (see e.g. here ).

@Carl Love 

This thread shows that the subject of mutable and immutable objects is still subdocumented. The chapter 4 of the Programming Guide has been an improvement, but it is not yet comprenhensive enough. E.g. where is the complete list of mutable data structures?

Equality by memory address is a check at the syntactic level, and this is OK for low level programming. But at the mathematical (or semantic) level, an isolation of those details is needed. The verify facility ( check ?verify ) is quite useful for this purpose (though little used). For instance:

> verify(table([0=0]),table([0=0]),table);
                                      true
> verify(Vector([3, 3])-Vector([3, 3]),Vector([0, 0]),Vector);
                                      true

Moreover it is quite flexible (check ?verify,structured ) and extensible (see e.g. here ).

@Hiker96 

Apparently, Maxima (5.24) behaves roughly the same as Maple about this issue:

(%i1) simpproduct:true;

(%o1) true
(%i2) ex1:a(1)*a(2)*product (a(i), i, 3, N);

(%o2) a(1)*a(2)*'product(a(i),i,3,N)
(%i3) ex2:product (a(i), i, 1, N);

(%o3) 'product(a(i),i,1,N)
(%i4) fullratsimp(ex1-ex2);

(%o4) a(1)*a(2)*'product(a(i),i,3,N)-'product(a(i),i,1,N)
(%i5) ex1-ex2,N=5;

(%o5) 0

And in a quick search I have not seen a suitable routine/package for handling symbolic products. But certainly, interesting work is being done in Maxima in the area of symbolic computation. So, if you ever happen to find something useful, it would be interesting that you report back. It might serve as an incentive to Maplesoft :)

@Hiker96 

Apparently, Maxima (5.24) behaves roughly the same as Maple about this issue:

(%i1) simpproduct:true;

(%o1) true
(%i2) ex1:a(1)*a(2)*product (a(i), i, 3, N);

(%o2) a(1)*a(2)*'product(a(i),i,3,N)
(%i3) ex2:product (a(i), i, 1, N);

(%o3) 'product(a(i),i,1,N)
(%i4) fullratsimp(ex1-ex2);

(%o4) a(1)*a(2)*'product(a(i),i,3,N)-'product(a(i),i,1,N)
(%i5) ex1-ex2,N=5;

(%o5) 0

And in a quick search I have not seen a suitable routine/package for handling symbolic products. But certainly, interesting work is being done in Maxima in the area of symbolic computation. So, if you ever happen to find something useful, it would be interesting that you report back. It might serve as an incentive to Maplesoft :)

Yes, I can reproduce it in Maple 16.02. It does not occur in Maple 17 nor in earlier versions that I have tried (15.01, 14.01, etc)

Yes, I can reproduce it in Maple 16.02. It does not occur in Maple 17 nor in earlier versions that I have tried (15.01, 14.01, etc)

@Hiker96 

Yours is an interesting point. A simpler example in ordinary in 1D input is useful as it makes it more clear:

> ex1:=a[1]*a[2]*product(a[i],i=3..N);
                                        /    N          \
                                        | --------'     |
                                        |'  |  |        |
                       ex1 := a[1] a[2] |   |  |    a[i]|
                                        |   |  |        |
                                        |   |  |        |
                                        \  i = 3        /

> ex2:=product(a[i],i=1..N);
                                        N
                                     --------'
                                    '  |  |
                             ex2 :=    |  |    a[i]
                                       |  |
                                       |  |
                                      i = 1

> simplify(ex1-ex2);
                          /    N          \   /    N          \
                          | --------'     |   | --------'     |
                          |'  |  |        |   |'  |  |        |
                a[1] a[2] |   |  |    a[i]| - |   |  |    a[i]|
                          |   |  |        |   |   |  |        |
                          |   |  |        |   |   |  |        |
                          \  i = 3        /   \  i = 1        /
> simplify(eval(ex1-ex2,N=5));
                                       0

The issue here is the mix of an explicit product (an expression involving `*`) and an unevaluated product function call with symbolic limit. The reality is that Maple does not provide a ready to use command to transform this mix into a product call over the combined index range. In particular, simplify is unable to do it, hence not returning 0. 

In principle, if needed, such routine coud be programmed. But really what is missing in Maple is a "ProductTools" package including symbolic computation features like this transformation.

@Hiker96 

Yours is an interesting point. A simpler example in ordinary in 1D input is useful as it makes it more clear:

> ex1:=a[1]*a[2]*product(a[i],i=3..N);
                                        /    N          \
                                        | --------'     |
                                        |'  |  |        |
                       ex1 := a[1] a[2] |   |  |    a[i]|
                                        |   |  |        |
                                        |   |  |        |
                                        \  i = 3        /

> ex2:=product(a[i],i=1..N);
                                        N
                                     --------'
                                    '  |  |
                             ex2 :=    |  |    a[i]
                                       |  |
                                       |  |
                                      i = 1

> simplify(ex1-ex2);
                          /    N          \   /    N          \
                          | --------'     |   | --------'     |
                          |'  |  |        |   |'  |  |        |
                a[1] a[2] |   |  |    a[i]| - |   |  |    a[i]|
                          |   |  |        |   |   |  |        |
                          |   |  |        |   |   |  |        |
                          \  i = 3        /   \  i = 1        /
> simplify(eval(ex1-ex2,N=5));
                                       0

The issue here is the mix of an explicit product (an expression involving `*`) and an unevaluated product function call with symbolic limit. The reality is that Maple does not provide a ready to use command to transform this mix into a product call over the combined index range. In particular, simplify is unable to do it, hence not returning 0. 

In principle, if needed, such routine coud be programmed. But really what is missing in Maple is a "ProductTools" package including symbolic computation features like this transformation.

@Preben Alsholm 

True, the behavior of Student:-Precalculus:-CompleteSquare is unsatisfactory when called with more than one component for the second argument (this is why I have said above "one of the problems"). A remarkable illustration of its capacity for writing zero in multiple ways has been given a high profile by Maplesoft itself in ?updates,Maple17,SmartPopups > Complete the square. And note that I have reported on this problem long time ago.

@Preben Alsholm 

True, the behavior of Student:-Precalculus:-CompleteSquare is unsatisfactory when called with more than one component for the second argument (this is why I have said above "one of the problems"). A remarkable illustration of its capacity for writing zero in multiple ways has been given a high profile by Maplesoft itself in ?updates,Maple17,SmartPopups > Complete the square. And note that I have reported on this problem long time ago.

I would like to jump one decade after John's story. I began working as Maplesoft ambassador in Argentina in mid 1994 and for almost two years I made my presentations with the then current version Maple V Release 3 for Windows. Its GUI run on DOS+Windows 3.1, and it was very nice, tiny and stable. Actually much more stable than the underlying Windows 3.1 patch on DOS. Compare Standard GUI vs OS wrt stability nowadays...

And indeed it was tiny. The omnipresent question that I received as ambassador was: "how does Maple compare with Mathematica?". And a strong point that I had at that time was: "Mathematica needs at least an 8MB RAM machine, while Maple works confortably in a 2MB machine". Note that at that time, very few machines had 8MB RAM here, at least in the academic sector. And despite being so economical in computational resources, Maple's GUI had features not available in Mathematica's GUI. For instance, Maple 3D plots remained visible while being rotated, but Mathematica showed only a box. Moreover, rotation could be made with the arrow keys (besides the mouse), a feature sadly lost in later Maple versions.

In my opinion, it is a pitty that those good design principles were left aside along the road. So, I also make a request for a return to the roots.

Even more than a strange name for this operation, it is a complete contradiction of its documented purpose, as ?combine states:

The combine function applies transformations which combine terms in sums, products, and powers into a single term.

In fact, combine ends up calling a routine computing a Fourier expansion:

> trace(`tfourier/sin`):
> ex:= (sin^3)(x):
> combine(ex);
{--> enter tfourier/sin, args = 3
                                    x := _X
                            -2 sin(3 _X) + 6 sin(_X)
<-- exit tfourier/sin (now in trig/tfourier) = -2*sin(3*_X)+6*sin(_X)}
                           -1/4 sin(3 x) + 3/4 sin(x)

> showstat(`tfourier/sin`);
`tfourier/sin` := proc(n)
local k, x;
   1   x := _X;
   2   if n = 0 then
   3     1
       elif irem(n,2) = 0 then
   4     (-1)^modp(1/2*n,2)*((-1)^(1/2*n)*binomial(n,1/2*n)+2*sum('(-1)^k*binomial(n,k)*cos((n-2*k)*_X)',k = 0 .. 1/2*n-1))
       else
   5     2*(-1)^modp(1/2*n-1/2,2)*sum('(-1)^k*binomial(n,k)*sin((n-2*k)*_X)',k = 0 .. 1/2*n-1/2)
       end if
end proc

What is most remarkable as a Fourier series tool is missing at user level.

Even more than a strange name for this operation, it is a complete contradiction of its documented purpose, as ?combine states:

The combine function applies transformations which combine terms in sums, products, and powers into a single term.

In fact, combine ends up calling a routine computing a Fourier expansion:

> trace(`tfourier/sin`):
> ex:= (sin^3)(x):
> combine(ex);
{--> enter tfourier/sin, args = 3
                                    x := _X
                            -2 sin(3 _X) + 6 sin(_X)
<-- exit tfourier/sin (now in trig/tfourier) = -2*sin(3*_X)+6*sin(_X)}
                           -1/4 sin(3 x) + 3/4 sin(x)

> showstat(`tfourier/sin`);
`tfourier/sin` := proc(n)
local k, x;
   1   x := _X;
   2   if n = 0 then
   3     1
       elif irem(n,2) = 0 then
   4     (-1)^modp(1/2*n,2)*((-1)^(1/2*n)*binomial(n,1/2*n)+2*sum('(-1)^k*binomial(n,k)*cos((n-2*k)*_X)',k = 0 .. 1/2*n-1))
       else
   5     2*(-1)^modp(1/2*n-1/2,2)*sum('(-1)^k*binomial(n,k)*sin((n-2*k)*_X)',k = 0 .. 1/2*n-1/2)
       end if
end proc

What is most remarkable as a Fourier series tool is missing at user level.

@Muhammad Ali 

Fine. So, four options might be needed to please everybody: flashing underline, flashing boxes, both, none.