@Carl Love 

I am not sure to understand what you mean. If that complexity is something inherent to the polynomial rather than a measure of how the polynomial is written, does it mean, for instance, that it remains invariant under a linear change of variables?

@Carl Love 

I am not sure to understand what you mean. If that complexity is something inherent to the polynomial rather than a measure of how the polynomial is written, does it mean, for instance, that it remains invariant under a linear change of variables?

@ecterrab 

A local dummy approach, requires an adapted set of tools, and indeed it will not work otherwise. My feeling is that the hybrid model will become inconsistent at some point. But if there is no theoretical background to prove in one way or another, it is OK trying and see what happens.

@Carl Love 

Maple has a variety of measures of size/complexity of the expressions like length, `simplify/size/length`, `simplify/size/size`, `simplify/size/size/object` and SolveTools:-Complexity.

Most of them are undocumented, but I guess that they are somehow based on Computational complexity theory (or time complexity).

@Carl Love 

Maple has a variety of measures of size/complexity of the expressions like length, `simplify/size/length`, `simplify/size/size`, `simplify/size/size/object` and SolveTools:-Complexity.

Most of them are undocumented, but I guess that they are somehow based on Computational complexity theory (or time complexity).

If the dummy sum index were represented by a "local name" within the sum call, then the third example:

> a := 1; b := 2; k := j;
> sum(f(j, k), j=a..b);

should yield f(1, j) + f(2, j), with global j as second argument in these function calls.

Certainly, it is my opinion that dummy variables should have been represented by local names or using some evaluation rule with equivalent effect, in definite sums, products and integrals. Idem in the repetition statements (for loops) and similar structures. Meaning that they should work the same as seq or add here, with the index "isolated" from assignments to the global name:

i:=2;
                               2
seq(i,i=1..6);
                        1, 2, 3, 4, 5, 6
add(i,i=1..6);
                               21

There are examples of a similar implementation in other CAS.

@Mac Dude 

Your point about not being paid to debug Maple but to produce results is correct. But it is also correct that as you get deeper into it, Maple seems rougher than necessary or acceptable. 

So, it is very likely that bugs that you do not report will not be fixed. And if you keep getting deeper you will spend more and more time looking for workarounds. And at some point you may find that you will need to debug for finding some workarounds...

@awass 

I bet that the "gremlin" is some implicit multiplication in 2D input (or actually, the designer of the 2D language...). My advice: use always 1D input (consequently explicit multiplication), it will save you from a lot of headaches!

@Andriy 

Certainly, and in this interesting thread, Jacques has commented:

[My understanding] is that there really are now 2 Maple languages, 1d and 2d, which are (unfortunately?) extremely similar.  If they were consistent, then implicit multiplication would be available (or not) in both, which is not the case.

Having 2 languages in the same system is not necessarily bad.  Having 2 languages which have 99% of features in common, now that is something which is a recipe for disaster!  It basically means that you never know if what you learn in one context can be transported to the other (or not)....

And an additional ingredient to this recipe is that these two languages largely share a common documentation, with their differences barely explained in some sentences, frequently mixed among other stuff.

@Andriy 

Certainly, and in this interesting thread, Jacques has commented:

[My understanding] is that there really are now 2 Maple languages, 1d and 2d, which are (unfortunately?) extremely similar.  If they were consistent, then implicit multiplication would be available (or not) in both, which is not the case.

Having 2 languages in the same system is not necessarily bad.  Having 2 languages which have 99% of features in common, now that is something which is a recipe for disaster!  It basically means that you never know if what you learn in one context can be transported to the other (or not)....

And an additional ingredient to this recipe is that these two languages largely share a common documentation, with their differences barely explained in some sentences, frequently mixed among other stuff.

Maple's implementation of Dirac as a point function, as used here, is misleading in my opinion. And I find that it sends a wrong signal to people not familiar with this subject (confusing point and generalized functions). Probably, the "characteristic function" charfcn is a more reasonable choice for this role. Something like:

g := i->a*charfcn[1](i):
h := f->sum(g(i), i = 1 ..f ):
h(2);
                               a
h(-2);
                               0

Maple's implementation of Dirac as a point function, as used here, is misleading in my opinion. And I find that it sends a wrong signal to people not familiar with this subject (confusing point and generalized functions). Probably, the "characteristic function" charfcn is a more reasonable choice for this role. Something like:

g := i->a*charfcn[1](i):
h := f->sum(g(i), i = 1 ..f ):
h(2);
                               a
h(-2);
                               0

@Carl Love 

For instance, ?keyword#Description, 2nd bullet item states:

If one of these words must be used as a name, such as in a call to the help function, it must be enclosed in left single quotes (back quotes) (` `) in 1-D Math notation. For example, help(`if`) gives an explanation of the if statement. In 2-D Math notation, back quotes are not necessary.

After this paragraph, "back quotes are not necessary". So, help(if) should work in 2D. But it gives an error:

help(if);
Error, invalid bracketed expression
Typesetting:-mambiguous(helpApplyFunctionTypesetting:-mambiguous(

  (if), Typesetting:-merror("invalid bracketed expression"))semi)

And it does not work with back quotes either:

help(`if`);
Error, Got internal error in Typesetting:-Parse : "internal error in PostprocessRec: if"
 Typesetting:-mambiguous(Typesetting:-mambiguous(

   helpApplyFunction(grave;if&grave), Typesetting:-merror("Got 

    internal error in Typesetting:-Parse : "internal error in 

    PostprocessRec: if"")))

There are several other examples that I could show of keywords in 2D not working as stated in that help page.

@Carl Love 

For instance, ?keyword#Description, 2nd bullet item states:

If one of these words must be used as a name, such as in a call to the help function, it must be enclosed in left single quotes (back quotes) (` `) in 1-D Math notation. For example, help(`if`) gives an explanation of the if statement. In 2-D Math notation, back quotes are not necessary.

After this paragraph, "back quotes are not necessary". So, help(if) should work in 2D. But it gives an error:

help(if);
Error, invalid bracketed expression
Typesetting:-mambiguous(helpApplyFunctionTypesetting:-mambiguous(

  (if), Typesetting:-merror("invalid bracketed expression"))semi)

And it does not work with back quotes either:

help(`if`);
Error, Got internal error in Typesetting:-Parse : "internal error in PostprocessRec: if"
 Typesetting:-mambiguous(Typesetting:-mambiguous(

   helpApplyFunction(grave;if&grave), Typesetting:-merror("Got 

    internal error in Typesetting:-Parse : "internal error in 

    PostprocessRec: if"")))

There are several other examples that I could show of keywords in 2D not working as stated in that help page.

@Carl Love 

I wonder what exactly are keywords in 2D input. Certainly, ?keyword does not explain correctly this issue in the 2D language.