@acer I added back the negative sign in the last step, but combine would have been better. I'm always nervous about doing things by hand, and was hoping IntegrationTools:-Expand would put the integral inside the sum.

@one man Thanks. I first played round with it with various options in PolynomialSystems without much success. My past experience has been that the polynomial system doesn't have to be very large before it is intractable, but once @vv showed it could be done I wanted to pursue it a bit more.

Please provide some more details, including your Maple version, and preferably uploading some sample files (with the green up-arrow).

In Maple 2024.2, if I have two worksheets A and B open, and copy contents from A into the middle of B, the equation labels in B are automatically renumbered. Are you using some other method?

I agree; this is very frustrating. The vertices are pixellated because each plot is exported at lower resolution than if exported separately. This is for the elements that are bitmaps, the pdf export properly renders the lines and the fonts.

This is much more noticeable when exporting arrays of 3d plots of surfaces. I found that exporting to html and then printing to pdf (using Adobe print driver) from the html gives higher resolution for the bitmap elements but poorer resolution for the fonts and lines - it also doesn't respect the page breaks.

So my standard for publications is to export the individual plots to .eps and assemble the array of plots in another piece of software, e.g., CorelDraw.

@MaPal93 I wasn't suggesting the different results were pathological, rather that there was some minor error somewhere. A pathological case might occur for example if you want lim(a(x)*b(x),x=infinity). You evaluate lim(a(x),x= infinity and find it is infinity. Or you evaluate limit(b(x),x=infinity) and find it is zero. You cannot conclude anything from this, because we could have a=x^2 and b=1/x^2 and the true limit is 1. But if both limits are finite and non-zero, you should be OK.

I redid the calculation and simplification steps, checking numerically at each step. The result is different from above. To find out why, you could apply the same numerical checks to the other procedures to track done what is probably some small error in one step. (Edit: I see you figured this out.) But W4 is achieved without any limiting process, and is verifiably correct. If you rerun with gamma = 1e8, you see that W4 and the limiting values agree. So I am confident this version is correct.

limits.mw

@MaPal93 I wanted to check the limit for the RootOf, since there was some error with an earlier example that I submitted an SCR for, but at least for lambda it looks OK. You could pursue the sort of numerical tests I do here to resolve the discrepancy.

same3.mw

@MaPal93 I can imagine some pathological cases, but in general I would expect that the results should be the same. If I use limit(X[i], gamma = infinity) in generic_n-form_of_infinity_limit2_MaPal.mw I don't get the expression for X[i] in  n_from_2_to_6_-_not_coincide.mw so perhaps something is incorrectly entered, or perhaps I am not understanding what you are doing.

@MaPal93 I rewrote with as few summations as possible and was able to get the following simple result:

generic_n-form_of_infinity_limit2.mw

The _a indices arise when it would otherwise lead to a summation over i inside another summation over i, which is confusing since they are only dummy indices and not related. So Maple makes sure they have different names.

@MaPal93 I don't have any specific suggestions other than try to figure out the patterns.

Download patterns.mw

@MaPal93 Actually, I realized that if you use collect(W, gamma) (first method) you see W = (stuff1)*gamma+(stuff2), so the limit will be +infinity if stuff1 > 0 and -infinity if stuff1 < 0. So it seems correct that is infinite. (But now you have new X[i] etc.)

In general if you see something like signum(n*rho - rho + 1) you can just make some assumption like n*rho - rho + 1>0 to make it go away, assuming that such an assumption is valid.

@salim-barzani So if the input is 1/G(xi)*($$$$$$$$$$$$+diff(G(xi),xi)*(##########) what is the output you want?

I don't understand what you are trying to do, but this might be useful.

collect.mw

I don't think there is any simple way. Since you want several matrices, GenerateMatrix won't work directly. You can use dcoeffs to find the pieces and then assemble them into the matrices.

@janhardo The DLMF (and the corresponding hardback book version) is produced by NIST (National Institute of Standards and Technology) in the U,S., and is the successor to Abramowitz and Stegun's, "Handbook of Mathematical Functions"; it is considered an authoritative source, perhaps "the" authoritative source.

These differential equations are standard forms in the sense that they are often quoted, e.g., one speaks of "Bessel's equation"  and there is a common way to write it, though of course there is not universal consistency in these things. 

But in terms of classifications in a text as I think you want, there is probably not much of a standard. I personally like Zwillinger's "Handbook of Differential Equations". Of course these classifications exist because of different solving methods, but since the objective is often a special function, they are related to the other standard forms.

Maple' odeadvisor(verg) gives: [[_2nd_order, _missing_x], [_2nd_order, _reducible, _mu_x_y1]]

Since many of the second-order differential equations and their "special" functions are related through transformations to the Sturm-Liouville eqation, perhaps it is the standard form to rule them all :-).

@MichaelVio Here's an example.

Download dchange.mw