I am unsure of the root cause of the discrepancy. You could resolve that particular inconsistency with,

   int(..., numeric, method=_Dexp)

or,

   evalf(Int(..., method=_Dexp))

Also, your integrands may be complex-valued due to floating-point (ie. approximate) coefficients along with the presence of I, the imaginary unit.

You may get rid of small floating-point imaginary artefacts in results by wrapping the results in call to fnormal.

You may get rid of 0.0*I imaginary components of a result by wrapping in a call like simplify(...,':-zero').

Eg,
   simplify( fnormal( evalf(Int(..., method=_Dexp) ), ':-zero');

I don't understand why you apply evalf to the integrands passed to the quadrature call.

Btw, while you might be deliberately trying numeric quadrature for speed (say), much of your results can be obtained using exact symbolic computations (including erf calls in results) if you use exact rationals instead of floating-point values for your parameters, etc. In at least one way that can also symbolically show that the imaginary part of your integral is exactly zero.

The following is not real-valued for purely real x. But it's not awful.

Download intfun1.mw

I don't know how to get it as H or F in the Comments on the Question, which are real-valued for real x.

I'm not sure exactly how the names you used figure in the process.

But perhaps something like the following can be turned to your purpose.

Download memoi.mw

Here is one way:

Download some_set_stuff.mw

If you really want you could devise an overloaded scheme where those names union, minus, and intersection act similarly (say, by performing the operations such as I showed, underneath).

You may pass the option explicit (or explicit=true) to the solve command and obtain the explicit roots of a 4th degree polynomial directly, with a single command.

For your example, say,

    solve(Opt_effort_FOC = 0, e[n], explicit)

Inside the procedure p2 you need to use the global name :-debug as the name of the keyword option when it calls procedure p1.

p1 := proc(a, b, {debug::truefalse := false})
   print("p1", debug);
   a + b;
end proc:

p2 := proc(a, b, {debug::truefalse := false})
   print("p2", debug);
   p1(a, b, ':-debug' = true);
end proc:

p2(1, 2, 'debug' = true);

              "p2", true
              "p1", true
                  3

Otherwise your p2 is calling p1 with true=true, since inside p2
    debug = true
evaluates using the value of the p2 parameter that is also named debug.

Here is what's happening in your original. Notice the arguments that p2 passes to p1 include
   true = true
and not
   debug=true
which was what you'd expected.

restart;

p1 := proc(a, b, {debug::truefalse := false})
   print("p1", debug);
   a + b;
end proc:

p2 := proc(a, b, {debug::truefalse := false})
   print("p2", debug);
   p1(a, b, debug = true);
end proc:

trace(p1):
trace(p2):

p2(1, 2, 'debug' = true);
{--> enter p2, args = 1, 2, debug = true
                           "p2", true

{--> enter p1, args = 1, 2, true = true
                          "p1", false

                               3

<-- exit p1 (now in p2) = 3}
                               3

<-- exit p2 (now at top level) = 3}
                               3

Now observe what happens in the corrected version. Notice what arguments p2 passed to p1.

restart;

p1 := proc(a, b, {debug::truefalse := false})
   print("p1", debug);
   a + b;
end proc:

p2 := proc(a, b, {debug::truefalse := false})
   print("p2", debug);
   p1(a, b, ':-debug' = true);
end proc:

trace(p1):
trace(p2):

p2(1, 2, 'debug' = true);
{--> enter p2, args = 1, 2, debug = true
                           "p2", true

{--> enter p1, args = 1, 2, debug = true
                           "p1", true

                               3

<-- exit p1 (now in p2) = 3}
                               3

<-- exit p2 (now at top level) = 3}
                               3

By the way, I wrote as ':-debug' = true so that it would work even if the global name :-debug had also been assigned a value (at the top-level, say). Strictly speaking I didn't have to do that, since :-debug is a protected name. But for the same situation involving other (unprotected) names you could have that situation. So I wanted to illustrate to you the more robust way.

[note: See here for details I gave in your earlier Question thread, for plotting the 0-contour using interpolation of 0-height data that is computed more robustly. That seems to make this Question thread less relevant...]

You appear to be using Maple 2021, so you can use the newer Interpolation package (new in Maple 2018), which makes the task of interpolation "on-the-fly" easier.

The black-box that it returns can be subsequently polled at arbitrary x-y pairs, so you can easily use it with the contourplot command.

The problem is that you original data is quite flat for higher y-values, and the data you generated for it seems to lack enough precision to allow the 0-contour to be traced out nicely. (I alluded to this in your earlier Question thread, since I had already tried what I show below...)

In the plot below you can see that it has difficulty following the 0-contour, and slight inaccuracy in the original data can cause it to veer off the (exact) course.

Using ArrayInterpolation would not fix this issue, in and of itself. That command merely provides a mechanism to compute all the interpolated x-y target points in batch. I suspect that a good fix would require greater accuracy in the originally generated data -- which would be slower, and you earlier asked for it to be faster. It's possible that a scaling of the data to give it greater slope might be a kludge. But since the curve represents a function (in the mathematical sense) then it be more robustly found using fsolve (to find the alpha corresponding to each beta); again, see here.

Download test1_interp_acc.mw

It's not very helpful to split these detail and highly related queries across multiple Question threads. At this time the .xlsx data file is at attachment in your earlier thread, but not in this one. And the quantitative nature of that data bears on which are decent courses of action.

Please try to keep your related queries in the same thread, even if nobody yet answers all to your satisfaction.

There is a special substructure of a 2D plot which the GUI recognizes as instructions for filling a popup box when the mouse-pointer's focus lies over that particular plot feature.

You can build that into your individual plot features (curves, points,...) by using the annotation option.

See the Help page for Topic plot,annotation .

Download Q_9-9-22_limit_in_integral_ac.mw

The names generated by solve come in only a few flavours, so you might be able to get by without need for consideration of the names in the original expression f. For example,

restart;
assume(M::nonnegative):
f := 10*cos((-1+t)/sqrt(1+M))-10*cos(t/sqrt(1+M)):
g := solve({diff(f, t), t>0 }, t, allsolutions)[1][1]:

indets(rhs(g),And(name,Not(constant),
                  ':-suffixed(:-_)'));

           {_Z2}

indets(rhs(g),And(name,Not(constant),
                  ':-suffixed({:-_B,:-N,:-_Z})'));

           {_Z2}

I don't see a natural reason to attempt a heavy handed approach like as follows. (The original expression might have already had such generated names, in which case a combined approach might be needed.)

convert(indets(f,And(name,Not(constant))),`global`):
convert(indets(rhs(g),And(name,Not(constant))),`global`) minus %;

           {_Z2}

Simpler results can be had in Maple 2022.1, using the method below.

Perhaps someone can come up with something more direct. I programmatically determine the second root, to be less ad hoc about passing a range to Calculus1:-Roots.

The Calculus1:-Roots and maximize commands have a special (peppering) technique for determining values of the _Zxx assumed-integer parameter that solve returns here when passed its allsolutions option.

The solve command has improved in the past few releases, as far as returning a finite number of explicit roots when passed inequalities that denote a finite range. But it still seems not generally as strong as that internal technique of Roots and maximize. For this example solve returns a general formula when supplied its allsolutions option, but seems to return NULL when instead passed various reasonable inequalities, e.g t>0,t<10.

Here it is first with Maple 2015.2,

Download ToyProblem_ac2015.2.mw

And here that is in Maple 2022.1,

Download ToyProblem_ac2022.1.mw

Is this the kind of thing you were trying to accomplish?

I wasn't sure whether you wanted only the floating-point approximate root where f(n)=g(n), or an exact result for that, or the next highest integer above that where f(n)>g(n).

Download ex1.mw

An exact result is also possible, in terms of the LambertW special-function.

solve({f(n)=g(n),n>5},n):

    { n = -8/ln(2)*LambertW(-1,-1/8*ln(2)) }

evalf(%);

   {n = 43.55926044}

Your Question shows an unevaluated call to intervalsolve, as a returned value. There is no such command in stock Maple. There is such a command in the Gym package (used by Danish schools). If using that command was your intention then you made two mistakes:

1) Your unevaluated return value shows that you failed to refer to its name properly. You could either use the command's fully qualified name (by including its package name in the call), or you could first load the package and then use the command's short name. See below, for examples of both.

2) The calling sequences of arguments that you passed is also incorrect for that Gym package's command. See below.

Here below is that command working in Maple 2021.2, called in a few alternate ways.

(These produce the same results in Maple 2022.1 and Maple 2020.2. You didn't tag your Question with your Maple version number; that can be useful information for us if it's an old version.)

Download intervalsolve_Gym.mw

plot( x, labels = [ `&Aring;`, y ],
         labelfont = [ Times, 14 ] );

Alternatives include the following (the Mapleprimes backend doesn't render them all, but my Maple 2022.1 GUI does):

`Å`
`Å`
`Å`

There is also,
   `#mo("&Aring;");`
which renders in upright Roman, instead of italic. It's possible to get alternate fonts with this upright variant, but it's messier and in that case you might well find Tom's Unit(angstrom) suggestion easier. For the italic, the above seems to work as well with alternate font families.

See also here, if you're more generally interested in fantastic beasts and where to find them.

unapply(x*cos(x), x)

or, in your example,

unapply(f,x)

where x is the intended symbol that appears in the expression to which f evaluates.

Below, CL is a list of the coefficients of powers of e^(-gamma*tau).

Is that what you're after?

Download How_to_collect_Coefficent_ac.mw

ps. Your expression contain e^(-gamma*tau) which is not the same as exp(-gamma*tau). Is that intentional?