## 197 Reputation

15 years, 205 days

## Corrected...

@vv Thanks. I corrected the link.

## My example was just to illustrate the pr...

@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]

## Not quite what I was looking for....

@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]

## Meant n=0...

@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.

## Meant n=0...

@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.

## Assume variables are incorrect....

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

## Oy vey!...

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

Everything is then ok.

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

## You are correct. It doesn't work on prev...

@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?

## Not quite what I was looking for....

@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.

## Need to do computation too....

@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?

## Override high DPI scaling behavior....

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.

## Great idea...

@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!

## Great minds and all......

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.

## I want the grid...

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.

## Clarifications on the Clarifications...

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.

 1 2 3 4 5 6 Page 1 of 6
﻿