@mmcdara Nice analysis. Vote up. No, I don't have the GlobalOptimization toolbox.

@Ariathm It might be finding the wrong local minimum. In non-linear least square problems like this getting the initial guess values close to the right answer is key to success, and I might have chosen some bad values.

I noticed p__eng is strangely like p__3 but not quite. Perhaps it is better to calculate these in Maple from some earlier expression, rather than enter them by hand. Especially if you have some form without the fractional powers, it will help.

@dharr The long calculation has probably to do with the difficulty of finding derivatives for the horrible expression. The following simplifies the expression enough that it proceeds to a solution. I used simplify(..,symbolic) to get rid of the fractional powers. In principle that can give invalid results, but here I think it is probably OK since everything is positive, but you should check that the answer makes sense. Note that the kappa value found is at the end of the range.

test2.mw

Looks OK, given that kappa is not correct yet

test3.mw

The error message is "Error, (in fsolve) {delta[0], y[0]} are in the equation, and are not solved for", and indeed you have not given values for delta[0] or y[0].

For future reference, it is easier if you upload your worksheet using the green up-arrow in the Mapleprimes editor.

@michele Since you now get the same answer, you and I are now almost certainly checking the same polynomials, so the ratios between our times is now meaningful. For other polynomials the time will be different,, e.g., after running the worksheet, go back to the execution group with p:= etc and hit enter, then enter on the CodeTools:-Usage line and your answer will have x^25268 in and the time will be about 50% longer. If you choose 2 polynomials with gcd = 1, the times will be significantly longer.

Bottom line: it depends on the polynomials.

@michele I'm just worried that for different versions of Maple, different number of random numbers might be used, leading to a diffferent answer for later calculations, even if the first one, r, is the same. An across-versions comparison might need to save the actual polynomial to an .m file and the read them in. That seems like overkill, so try running this to see if you get the same answer, and then the timing comparisons might make more sense.

Edit: 13th Gen Intel(R) Core(TM) i5-1335U   1.30 GHz; 16.0 GB RAM, in "best performance" mode.

Download gcd.mw

@michele The version of Maple could make a difference here, and the exact random numbers might not be the same (which seems to be the case in the second example because a different answer is obtained). Different polynomials might take different times so unless you average a lot of examples, it is hard to know what an average time is. So for the class polynomials you are using these might not be typical.

So are these results not acceptable to you? You are getting answers without crashes for what I would call large degree polynomials. Your CPU and real times are the same suggesting only one CPU, and perhaps an older computer without multiple cores?

I assume grade means degree here? Some further details about typical coeffs, number of terms, degree etc would be helpful. For integer coeffs, dense or sparse number of terms, degree 10^5 seems feasible, but with both degrees 10^6, it took longer than I was willing to wait. (This was Maple 2024 on Windows 11.)
 

Download gcd.mw

@MaPal93 I'm not sure how they are chosen. They seem to be points with integer coordinates on a grid, but I suppose if a region was too small for that then some rationals would be chosen. Note that for regions 2 and 3, the horizontal axis has no particular significance. I think the basic idea is to have any point for which evaluation proves that the equations and inequalities are satisfied; in that sense it doesn't matter where in the region it is.

@C_R With floating point limits, it is supposed to switch to numerical integration. From ?int

"If any of the integration limits of a definite integral are floating-point numbers (e.g. 0.0, 1e5 or an expression that evaluates to a float, such as exp(-0.1)), then int computes the integral using numerical methods if possible (see evalf/Int). Symbolic integration will be used if the limits are not floating-point numbers unless the numeric=true option is given."

But the alternate form also gave a numeric answer with 0..1,0..1 which is not expected, unless the floats in the integrand triggered this.

@mmcdara Very nice. Vote up. 

For axes=normal, the default, I don't know how to change this, but if you are OK with axes=boxed, then the labels are on the other side.

@C_R So even for polynomials allvalues will use radicals for cubics unless told not to. So to avoid radicals, and possible missed solutions, it should be possible to tell dsolve to use solve to get a RootOf. It turns out it is not so simple, but it can be done without as much done "by hand" as I did above.

Download RootOf_stuff_2.mw

@Axel Vogt Yes, I noticed that early on, but it was unclear about what exactly the poster wanted. If the poster can explain the practical range of x that they want the integral for I might be willing to look more closely. I've had success with method = _do1akc in the past with oscillating integrals. But non-dimensionalization would be a good first step; I doubt reliable numerics can be found with the parameters ranging from 10^23 to 10^(-37). m is set to 1 but I'm not sure if this is just a test parameter. If it is later to have very different values that also would make a big difference since it multiplies x.

We are still missing a value for x.

The first integral is problematic, since the integrand

(-epsilon^2/(4*a^2) - tau*epsilon^3)*(cos(epsilon*x) - 1)/epsilon^2

goes to infinity as epsilon goes to infinity because of the tau* epsilon^3. Is the first factor perhaps intended to be within an exp?