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

Please put your followup queries on this here, not in wholly separate new Question threads.

@somestudent What are the allowed numeric ranges of w, x, and y?

@madhav123 I will not be able to look at this for the next 6 days.

If your last attachment is actually yet another revision, then I'd have to wait until I could examine what aspects you might have changed. (ie. you wrote "similar", but I suspect you've changed something important.)

Please be patient. Perhaps someone else will respond before I can.

(In the meantime, please don't spawn a separate Question thread on it, even if there's no other response here.)

@madhav123 It helps there to restrict the range.

Shear_coefficient_-_Papers_ac.mw

I changed your Post into a Question.

From now, on, please submit your queries as Questions.

@mmcdara Two minor comments:

1) Carl's reformulation can be had by,

   exp(simplify(ln(f))) assuming t>0;

2) If you don't want to have fiddle with resetting UseHardwareFloats (after setting it to false) then you could make your particular expression non-evalhf'able in the following kludgy but quick&temporary way,

   plot(eval(f,exp=%exp), t=0.9..1.12);

Since the default for UseHardwareFloats is deduced then you could also avoid evalhf by setting Digits>15 . So if you don't mind higher working precision then another way to get that temporary effect, without having to set/re-set Digits, is,

   evalf[16](plot(f, t=0.9..1.12));