@Preben Alsholm It is a typesetting extended "effect".

@pagan 

What do you think? Is it a bug or a feature? In a quick browse of Maple 14 updates, I have not found any mention to this change.

@pagan 

What do you think? Is it a bug or a feature? In a quick browse of Maple 14 updates, I have not found any mention to this change.

@JacquesC I wonder also whether there are "subtle differences" between using the uneval modifier on the parameter and using unevaluation quotes ('...') on the argument. If so, which ones?

In Maple 14:

seq(`^`(0,k),k=0..2);
                               0, 0, 0

In Maple 14:

seq(`^`(0,k),k=0..2);
                               0, 0, 0

@GeorgesL First 0^k is evaluated/simplified to 0 when called as argument. Hence, sum actually receives 0 as sumand:

trace(sum): 
sum(0^k,k=0..0);
{--> enter sum, args = 0, k = 0 .. 0
                         input := [[0, k, 0, 0], false]

                               subsIndexed := {}

                                  output := 0

                                       0

<-- exit sum (now at top level) = 0}
                                       0

So, this issue is at the stage of automatic simplification, I think.

@GeorgesL First 0^k is evaluated/simplified to 0 when called as argument. Hence, sum actually receives 0 as sumand:

trace(sum): 
sum(0^k,k=0..0);
{--> enter sum, args = 0, k = 0 .. 0
                         input := [[0, k, 0, 0], false]

                               subsIndexed := {}

                                  output := 0

                                       0

<-- exit sum (now at top level) = 0}
                                       0

So, this issue is at the stage of automatic simplification, I think.

@John May Certainly, a direct way to improve the weaknesses his tests show is implementing in Maple a rule-based stage and call it at a proper point, from int/indefinite, probably. I have made same tests in this direction that have shown very succesful.

I have the impression that the main focus of the Rubi project is indefinite integration, not its application to definite integration via FTOC. But if I understand Albert Rich correctly, it is possible to choose rules such that continuous indefinite integrals are chosen, when known. For sure this is the case for integrands involving trigonometric functions, as his papers with David Jeffrey have shown.

I have asked a comment about the performance of Maple indefinite integrator in the Rubi test suite at the end of this talk. But the quality of the audio was so bad that I have lost large part of what you said then, including your answer. And sadly, that last part was removed from the record.

So, would you be so kind to reproduce your comment here?

Certainly, I had expected listening some information about future developments for improving the performance of the integration sector.

It sounds like the same bug described here.

Those input expressions with lower and capital names have very different internal (Typesetting) representations. As you describe it, this problem seems to arise at the 2D parsing stage, previous to the ordinary (1D) simplification stage. So, as pagan has described already, simplify can do nothing when receiving those atomic names that typeset mimicking expressions.

The problem with 2D input is that it hides information, and there is no known record of the actual steps creating a worksheet/document with this stuff. This fact brings additional problems to Maple newcomers as may be that the problem is not easily reproducible by somebody else.

So, Axel's advise is wise: if you want to do math, and get advice when needed, your most reliable option is 1D input, and preferably in Classic GUI.

Those input expressions with lower and capital names have very different internal (Typesetting) representations. As you describe it, this problem seems to arise at the 2D parsing stage, previous to the ordinary (1D) simplification stage. So, as pagan has described already, simplify can do nothing when receiving those atomic names that typeset mimicking expressions.

The problem with 2D input is that it hides information, and there is no known record of the actual steps creating a worksheet/document with this stuff. This fact brings additional problems to Maple newcomers as may be that the problem is not easily reproducible by somebody else.

So, Axel's advise is wise: if you want to do math, and get advice when needed, your most reliable option is 1D input, and preferably in Classic GUI.

@pagan 

To the contrary, the single name RL seems fine as is, with dimension of resistance. Most likely referring to the resistance of an inductance.

@pagan 

To the contrary, the single name RL seems fine as is, with dimension of resistance. Most likely referring to the resistance of an inductance.