@sursumCorda 

Download maximize_bug_2018.mw

@Preben Alsholm Sorry, I don't think that I understand the objection.

I got bogged down in details, and forgot that I was intending to give an opion.

IMNSHO it would not be a good idea for fsolve to attempt to re-evaluate an unevaluated active int call under assumptions of any supplied range.

The evidence that one particular example might attain a root-finding speedup is insufficient justification.

There are many integrals which consume computation time that is significant relative to the purely numeric root-finding aspects. Hence any such hybrid symbolic-numeric approach would certainly need a (new) option to en/disable it, since fsolve is used in so many places in the Library. I also doubt that this could decently be enabled by default -- there would be just too many slowdown cases.

And there's not much good point in a rarely used new option name (to remember, and to remember to use sometimes) if it's also not difficult to attempt such a symbolic integration oneself, prior to calling fsolve. Adding a new option for a straightforward preliminary step (not itself direct part of the numeric root-finding algorithms) would not be good: a case of "optionitis".

@C_R Your later statements about plot are incorrect; it has no special evaluation rules and when passed f(x_0) that is evaluated up front by the kernel (with no special range knowledge getting used) and the integral result passed to plot as its argument (which then ends up calling int:-Numeric).

The differences in timing seen above relate to how the numeric computations and integrations are then performed. The fsolve command is much more particular about correctness and guarding for floating-point roundoff error (testing convergence, assurance that the result is actually a root, etc). For the examples above fsolve is taking longer than plot while performing fewer numeric integrations.

The timing differences shown above persist if operator-form calling sequence if used for both (as I mentioned), or if int is replaced by `evalf(Int(...))` with no special options.

I have not yet investigated the computation, but one guess is that it may be related to mishandling of bivariate limits.

If so, then I don't recall offhand seeing minimize/maximize changed to use the multivariate limit functionality new to Maple 2019. Of course I could be mistaken. But perhaps (in the absence of a supplied range) it's only considering the finite value at a saddle and -infinity.

Making this up now, I didn't check maximize yet,

restart;
u := (1+20230321)*x*y-(x^2+y^2)/2:
limit(u,[y=infinity,x=infinity]);
                 undefined

limit(u,[y=-infinity,x=-infinity]);
                 undefined

limit(u, x=infinity);
                 -infinity

limit(u, x=-infinity);
                 -infinity

It could turn out to be related to some other aspect of handling limits, or even something quite different.

What kind of plot do you want?

Do you want curves (listplot) of the real and/or imaginary parts separately? Do you want a pointplot of the pairs of real and imaginary parts of each number? Something else?

If I've made a mistake and offended anyone then I apologize. I won't touch any Question of the OP.

@chri69a9 I used a mix of using an external editor vi on the .mw file (to remove invalid Equation XML elements) and Open/Save using Maple 2023.0.

If you are using the green up-arrow and the Upload button in the popup dialog then you also need to use either the Insert Link or Insert Contents button within that same popup dialog.

What point is being made by this posting that would not be more appropriate as further discussion of this previous thread started by the same person?

@C_R This is somewhat misleading because you are using 2-argument eval which does a substitution. That is significantly different from the OP's approach of using actual assignment of the parameters, and 1-argument eval merely as an attempt to force re-evaluation.

There are lots of ways to get the desired result, and you've shown one. That is fine. But what you've stated is not an explanation of the OP's issues.

And your statement, "If you want to use eval you have to load the Standard package." is false. The substitution approach that you showed for Units:-Standard also works for Units:-Simple.

Download Units_simple_not_simplified_ac.mw

Please stop posting completely separate new Question threads on this example.

Instead, add your close followup and related queries on this example to one of your earlier Question threads on it.

Try to fully characterize precisiely what you're trying to accomplish, and what would be acceptable to you as a solution.

Please stop posting completely separate new Question threads on this issue.

@minoush82 Please stop posting completely separate new Question threads on this topic.

You wrote, "specific width", and you also wrote, "10 characters".

But ten characters does not have a specific width in general, if you're not using a fixed-width font.