Are you still looking to make more progress with this?

@Carl Love It may be possible to programmatically convert a LaTeX export to PDF, using some 3rd party tool on the OS.

@Chico Why is there apparently a multiplication between print and (val) in your second example?

@sursumCorda I see the problem in my Maple 2021.2, but not in my Maple 2020.2.

@delvin Your expression assigned the name fin contains the subexpression Psi(xi[n]) as well as instances in the name Psi.

Therefore it is not a polynomial in Psi. The command degree(fin,Psi) returns FAIL.

Perhaps your intention is to use something like one of these?
  degree(eval(fin, Psi(xi[n]) = Psi), Psi);    # returns 8
  degree(eval(fin, Psi(xi[n]) = _foo), Psi);  # returns 4

I don't see how we are supposed to be able to guess what it is your trying to do there.

Merely trying to get that to be polynomial in Psi by calling series on it seems like it could be a logical mistake to me.

Why don't you explain why you think that expression has a degree in name Psi?

Note that you had somewhat similar difficulties with calling degree in this and that previous, duplicate Question threads.

@sursumCorda We can generate that very terse solution by setting to zero any addends in a (arithmetically expanded) mixed GAMMA & Ei result which are constant w.r.t. x. And we can confirm that result.

Download Wh_ex1.mw

For fun, we can also get a GAMMA form, and obtain the previous result from it, and also get form almost as nice without going through and WhittakerM intermediate result, by a change of variables.

And we can check them all, including your tersest form, by expanding the difference of the differentiated result with the original, as an initial step in simplifying.

Download Wh_ex2.mw

More fun than a barrel of monkeys.

I will submit several bug resports, eg. the original weakness in int, and also that simplify needs the expand to get zero in the checks.

@delvin Please stop spawning wholly separate new duplicate Question threads for this problem. Duplicates get flagged as such and may be deleted.

If you have followup queries, then you could add them here instead.

For example, your latest worksheet DNLS.mw has runtime errors because you've mistakenly used square brackets as if they were expression delimiters. That's a syntax mistake. In Maple, wrapping with square brackets creates a list. Use round brackets as delimiters.  DNLS_ac.mw

You made the same kind of syntax user-error, by using square-brackets incorrectly as demimiters, in this previous, duplicate Question thread.

@delvin I know how to force it into the form you've given.

But the form you've shown is only a partial conversion to hyperbolic-trig form, and it seems a somewhat ad hoc choice, to me. I don't know what is your complete characterization of a class of such problems, from which this choice would follow.

Download eval_exp_2.mw

@delvin You are missing a comma, right before the equation for zeta__4 .

If you fix that syntax mistake then your substitution works. It broke because of your removal of the comma, not because of your choice of values.

ps. Do you know that by default the imaginary unit in Maple is denoted by the capital letter I ?  See also interface(imaginaryunit) if you want to change that to lowercase i.

@Hullzie16 I think the main speedup came from using method=_d01ajc.

That allows faster evalhf float evaluations of the integrand, I believe.

But it may be that its speed arises mostly from that particular forced method's making evalf(Int(...)) avoid costly investigation into whether the integrand has discontinuities. (There are other ways to get that effect, eg. by forcing unapply construction of an operator from the integrand. An operator-as-integrand is veiled from such symbolic poking about. But that seems unnecessarily complicated and has extra overhead, since it'd be repeated for each value of w and A. I didn't actually test whether this supposition is correct. Another possibility is that the default method ran into trouble trying to adaptively subdivide the interval of integration according to error estimates; but I didn't look. The forced _d01ajc does its own adaptive approach using external code. All round my choice just seemed simpler.

[edited] Since you may be somewhat new to Maple, I should mention the following. It's never a good idea to set Digits:=4. Reducing the working precision that low can break quite a few things.

Maple uses Digits for working precision, but a blanket low Digits setting should not be used as an attempt to simply get a coarser target accuracy. In general it's better to use default Digits (or higher), and then apply evalf[d] to round down numeric values.

Or, for numeric integration in particular, you can keep default Digits (or higher, and up to 15 if you want to retain faster evalhf'ability), while using evalf/Int's epsilon tolerance option to allow it to only strive for coarser accuracy. What I mean is that It's good to get individual float evaluations of the integrand at sufficient working precision to be adequately numerically accurate, while sometimes there can be a speed benefit by relaxing the overall accuracy requirement of the integral in total (which is what that epsilon option specifies). For example, if you only need, say, 5 digits of final accuracy for plotting purposes.

Are you saying that you want to find the smallest (negative) value in the given W range which attains the criterion?

If so, then you needn't check them all, once one is found (if using increasing values from W).

@vv You were too quick for me!  :)

Your phrasing that you want the l[j] to depend on a[1] and k[j] is not quite clear to me. The results already do, except that some of the results are in terms of implicit RootOfs (and some are free, eg. l[1]=l[1], etc).

It reads to me as if you're asking for the formulas to be explicit. If that's what you're after, then how do you plan to deal with the possibility that some of the resulting formulas might be very large?

For this attachment I've used Maple 16.02, the closest I have to your Maple 15.0.
   question_2_ac.mw

If instead you actually mean that you want some actual "restrictions" on parameters (eg, numeric bounds, something else?) then please describe such clearly.

Maple does not come with such a benchmark performance test suite.

What particular kinds of computations do you expect to do, for which you would like to get a comparison?

It really helps to be specific. There are some internal parts of Maple that utilize multiple CPU cores, but that only affects certain kinds of computation.

An example of a general discussion being quite unusefully sidetracked by just some very particular kinds of computation (eg. rank of a large float Matrix, the performance of which has little to no bearing on a great many other kinds of computations) is this old Post.

If you are actually trying to compute eigenvalues and associated eigenvectors then please put your close followup queries here, instead of in a wholly separate new Question thread.