@Christopher2222 I totally agree that Maple should implement angled tickmark labels: It seems like a standard feature of plotting software (mostly for histograms). As a stopgap measure until something like that is implemented, would it be useful to you to have a Pareto plot with one- or two-letter tickmark labels along the horizontal axis and a legend that matches the short labels to the actual labels?

I just want to clarify for less-experienced readers that the "labels" to which you refer are tickmark labels. Usually, the unqualified word "labels" in the context of Maple plots means axes labels, which can indeed be written horizontally or vertically.

@Carl Love Further observations and suggestions:

1. Instead of making a series approximation to the Wronskian, how about first testing via plots that your approximation to the HeunG functions is correct.
2. The Maple kernel can easily handle far more terms than the 20 you've been using. I've been using 50 terms and it's still essentially instantaneous. Just make sure that you don't try to display a huge number of terms on the screen; you'll blow away the GUI. Make sure to end your commands with colons. Applying the simplify command will drastically reduce the size of these expressions.
3. You seem to be mixing series expanded at t=0 and t=1. I don't kow why that's valid.
4. What happens to the t in wronski?
5. How does your approximation account for the HeunGPrime?

You haven't said that you've tried doing any of this in Maple. So try it first, and post a followup comment.

A slightly better workaround: Change Pi to pi, then reverse that after the symbolic summation.

A slightly better workaround: Change Pi to pi, then reverse that after the symbolic summation.

@digerdiga I know nothing about Heun functions, but I've been looking at this. Try comparing plots of Re, Im, and abs, in addition to argument. This might lead you to the wrongski in your wronski.

These are just my raw observations; they may be of no significance:

The series expansion has a singularity at p = 0. Other than that, both the Re and Im of the series expansion look simple functions of the form exp(a*p)*sin(b*p+c) for different a and c, but the same b.

@Markiyan Hirnyk I understand your solution mathematically, but what is the physical significance of any value of n other than 2 or possibly 3? And wouldn't the value of n be determined completely by the dimensions of k? Each ODE has dimensions of acceleration, L/T^2 (probably specifically meter/second^2 since g is given as 10).

@Markiyan Hirnyk I understand your solution mathematically, but what is the physical significance of any value of n other than 2 or possibly 3? And wouldn't the value of n be determined completely by the dimensions of k? Each ODE has dimensions of acceleration, L/T^2 (probably specifically meter/second^2 since g is given as 10).

To compute an answer, we need a numeric value for jj (or n). That value is going to depend on the units of k, which I suspect are 1/meter, in which case jj must be 2. But it seems strange that an exponent was specified as a variable. Also, wouldn't you rather have g be a more precise value than "10", like perhaps 9.8?

You'll need to end your commands with semicolons.

Please post your exact code in a plaintext format. In your transcribed code, you are missing some multiplication operators, and you have unbalanced quote marks and parentheses. Immediate problems that I see are that your definition of G does not use an earlier value of G (so G is not recursive), and that you attempt to define a recursive f with a simple assignment statement rather than defining f as a procedure (f:= h-> ...).

Could you give more details on the polynomials? They have 7 variables and integer coefficients. Roughly, how many terms? Roughly, what degree? Roughly, what is the magnitude of the coefficients?

Suppose there were a command to do what you want. What would you like that command to do with a*b + b*c + c*d?

In addition to lacking Maple relevance, this recent material from alex_01 is unoriginal, somewhat plagiarized.

Okay, I got it now. It's not your fault. The MaplePrimes editor often drops all the characters after `<` on a line.