Hi Réjean
,
Thank you for the report. This bug is now fixed in the development Maple. The new answer is:

Sum(Sum(a[u]*a[v]+2*a[u]*b[v],u = 1 .. n),v = 1 .. n);

                              n   /  n                            \
                            ----- |-----                          |
                             \    | \                             |
                              )   |  )   (a[u] a[v] + 2 a[u] b[v])|
                             /    | /                             |
                            ----- |-----                          |
                            v = 1 \u = 1                          /

Cheers,

   Austin

As Edgardo mentioned in another answer, the bugs you posted in simplify are now fixed, and the fixes are available in the Physics Updates (Maplesoft Physics Updates v.643 or higher) which can be used now if you have Maple 2020. These fixes are also expected to be included in the next dot release for Maple 2020.

I just want to give a bit of explanation about what happened because this bug indeed seemed a bit mysterious. First of all, the factorial functions were being converted to GAMMA using n! = GAMMA(n+1). The simplification that was then being applied was the following:

1/(GAMMA(x)*GAMMA(k - x)) = sin(Pi*x)/(Pi*Product(x - i, i = 1 .. k - 1));


which is generally valid when k is an integer as was the case in your examples. Typically, this is a useful simplification to make as the result only involves elementary functions. Unfortunately, when x is also an integer, the numerator in the rhs is sin(Pi*x) which evaluates to 0. There may also be factors in the denominator which are 0, either explicitly or under assumption. In such cases, it is better to avoid applying this simplification and indeed, Maple has been careful to recognize these cases and avoid this substitution in such cases for the most part. The one exception here is that it didn't recognize that if x is actually a summation index (as the n in your examples is), then it is implicitly assumed to be an integer, even though no such assumption has been explicitly made using the assume facility. The fix was to make the GAMMA simplifier aware that summation indices are also integers and to have it take extra care in those cases as well.

Note that in your last example, simplify(op4), the n in the expression op4 has neither an explicit nor implicit assumption of being an integer, so the above simplification still goes ahead (and is valid in general).

Austin Roche