@Carl Love 

I forgot to show that it doesn't optimize anymore. I am trying to keep the example simple.

Thanks.

@Joe Riel Thanks.

Just curious why it takes a double expansion?

@Carl Love
The coefficients are real.
Assume doesn't really answer the conjugation question. It should still be able to distribute the operation across the sum.

Assume doesn't change the result.

Further thoughts?

@vv Thanks. I corrected the link.

@Mariusz Iwaniuk I'm not trying to get the result; it is quite obvious. My example was a simplified version to draw attention to the root of the problem, i.e. Maple doesn't recognize the derivative of x^n (for n=0) as identically equal to zero when it is inside a Sum. This leads to other bizarre and erroneous behaviors.
[moderator: see edited Question and attachment]

@Scot Gould That is technically a correct result but not what I was looking for. It hasn't recognized that the n=0 term is identically zero.

Why does it matter? My question was just a simplified version of a more complicated question. I was trying to get to the root of the matter. Many problems result from not creating a special case for differentiation of the constant polynomial (e.g. x^0).
​​​​​​​[moderator: see edited Question and attachment]

@nm I meant the case of n=0. I've edited the post to reflect this.

This may be how computer algebra systems have traditionally worked, but it seems like a weakness to me.

Maybe the solution is really in how sum/Sum works.

@vv Hi. I meant to say for n=0. I have edited the original post.

I guess my problem is more with how simplifications are not done on the sum/Sum procedure. I was thinking it would be easier to do the simplifications if the n=0 term was expressly called out.

I'm answering my own question. My spreadsheet had incorrect "assume" commands.

First, I should have used "addtionally" instead of "assume."

Second, I should have had the limit of rho<1, not rho<-1.

@tomleslie This was me being stupid. I don't use assume very often, but when I do, I use it incorrectly.

I need to assume "additionally(rho<1)" instead of "assume(rho<-1)".

Everything is then ok.

Thanks for taking the time to look at this and reply.

@tomleslie 
You are correct. I went back and checked and the calculation does work correctly on Maple 2020 (or 2019 either).

So, it is a general bug with integration in Maple. The answer should be 1 - not infinity.

I had a worksheet doing the right thing the other day with similar calculations. Of course, it was so short I didn't bother to save the file! 

Do you agree Maple is generating an incorrect answer?

@Kitonum This isn't quite what I was looking for. I was looking for a way to do this in a more automated way. Certainly, I can hand manipulate things to get the correct answer in this case. As with any perturbation analysis, I may need even higher order partial solutions in epsilon - which means taking more derivatives with respect to epsilon. That would mean continually having to "babysit" the calculation to make sure everything simplifies appropriately.

The second part of your answer helps. Thanks. I may be able to use this to pull out only the relevant term.

Thanks again. 

 

@nm Thanks for the reply. I still need to be able to compute with them. [I edited my original question to clarify that].

Your suggestion is interesting, but not what I need. Just for more info, what exactly is the quote-quote doing here?

Having moved to a new laptop, I lost my old method for getting the screen sizing how I wanted it.
I discovered a "new" setting in Windows (10): "Override high DPI scaling behavior."
If you open the file location for Maple and right click for properties you will get the form shown below:
Select the "Override high DPI scaling behavior" property and set the "Scaling performed by:" to application.

If anyone has a better way to do this, I am all ears.

Regards.

@acer Thanks for the idea!

I probably will go silent for a few days as I have a higher priority item that needs attention.

I'll post when/if I get this working.

Thanks!