@ludvigpujsek Sorry, I meant to write unapply, not unassign. Oof.

I'll correct it in my Answer.

@MANUTTM A different range is required for t2.

Download q3m_ac_t2.mw

@mmcdara Yes, and content also has a Help page, which can be directly queried.

The content command has been in Maple for a long time.

The rhs of sort's key option isn't necessarily part of only the sort command. It can be something more general; in this case another command.

It is a shame that the OP's original example is so vague. We cannot know from it even simple aspects such as whether the sign of the coefficient matters.

@mmcdara The key option is explained in the Description section of the sort Help page.

That option was available in Maple 16.02 (released 2012). I don't think of that as "recent". I don't recall when it first appeared.

@dharr From the Options subsection of the Description section of the rtable Help page (emphasis, mine):

"The fill value is only used to fill those elements of the rtable that are unspecified in spite of the indexing function. For instance, the fill value is not used to fill the lower triangle of an upper triangular Matrix. For a sparse rtable, the fill value is always ignored."

@mmcdara You are querying the address of the values assigned to the entries of V, ie. the address of whatever V[1],etc, evaluate to. Those are not addresses of part of the V structure itself.

The address of the name s is the same, regardless. And the same goes for 1.

I don't see how your answer, "it's more a problem of visualization than a problem of storage" might be meaningful here.

I don't see how your use of addressof is useful to understanding here.

@jalal Do you mean something like this?

Download ruled-surface_ac.mw

note: Sometimes this kind of thing can be made more efficient (time and memory) by making plot3d's grid option depend on q, even to the point of re-use of prior computed values. That doesn't seem to be a requirement here, and the above code is simple.

@Carl Love Thanks. (I really should have thought of that, since it's a significant aspect of the command!)

The Explore command (and the right-panel's PlotBuilder) use Embedded Components.

The embedded PlotComponent does not yet support the colorbar's new plotting substructure.

Does it only happen if you Print directly? Does it occur if you export to PDF file?

Does it happen regardless of whether you use the Print Preview facility?

Does it only occur for 3D curves? If so, does it help if you explicitly add the option style=line?

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