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!

@Carl Love 

Hi,

Thanks for the suggestion. I had actually just tried thickness before I saw your post. It's sort of strange. The lines become blurry.

It seems like offsetting the grids may be the nicest looking approach.

The other possibility is to draw each gridline as a parametric plot and merge them all together. This would probably be slow.

@Carl Love 

I had played around with patchnogrid.

One thing I tried was to plot the surface [arg(z),20*log10(abs(z)),arg(z/(1+z))] vs. [arg(z),20*log10(abs(z))] with patchnogrid. I then made a separate plot of vs [arg(z),20*log10(abs(z)),arg(z/(1+z))] vs [arg(z/(1+z)),20*log10(abs(z/(1+z))] - which as mentioned above is equivalent to plotting [arg(w/(1-w)),20*log10(abs(w/(1-w))),arg(w)] vs [arg(w),20*log10(abs(w)))] - with wireframe. I then displayed these two plots together. It sort of did the right thing, but the grid was averaged into the first plot, resulting in faint lines.

I could make two grid plots and offset them +/- ever so slightly in the third coordinate direction. This would give the illusion of solid grid lines.

Any suggestions how to get dark lines when the two plots are merged.

@Carl Love 

You are correct about wanting to increase the plot's extent in the second coordinate dimension.

With regard to the formula, since my grids are parameterizations of w=z/(1+z), my first and second coordinates [parameterizations of z] need to be expressed in terms of w. z=w/(1-w). Hopefully this makes sense?

If I could put contours of arg(z/(1+z)) and 20*log10(abs(z/(1+z)) on the same arg(z/(1+z)) surface, that would be the easiest. As far as I know I can't put the 20*log10(abs(z/(1+z)) contours onto a plot of the arg(z/(1+z)) surface.

Thanks for looking at this.

@rlopez Thanks for the reply. The order the operations are imposed does not matter. Partials commute.

@Christian Wolinski 

Thanks for the reply. I don't think I am quite getting it.

Do you have an example of the difference?

Thanks.

@Christian Wolinski 

Thanks for the reply.

I experimented around and found that the uneval quotes make a difference - so I can get the expected behavior if I quote 'Heaviside'.

I'm not sure why Heaviside requires the quotes where other procedures do not?

As a side question, what is the distinction between patmatch and typematch?

Regards.

@tomleslie 
 
Thanks for the reply.

I definitely intend it to only match for type algebraic.

type(x,algebraic) returns true

I get a valid pattern match for an arbitrary function "f"

example.mw

My expectation is that if x is not algebraic that I would get a false match.

@Carl Love Thanks for the reply. I had seen the wrightomega function, but I'm not sure how this helps me. Maple will not solve for the wrightomega function, so I am stuck trying to get my answer onto the correct branch.