Are you perhaps looking for something like the following:

[seq(RootOf(det_num, Omega, index = i), i = 1 .. 3)];
plot(%, omega__v = 0 .. 2, size = [400, 400]);

I'm not 100% sure how your code is supposed to work.

On my machine the following takes about 14sec, compared to the original taking about 24sec.

Formula_II_acK.mw

(It's not easy to work with this code when it's "behind" a Button. But I've put my edits back there because that's how you gave it to us.)

A significant portion of the outstanding time is now taken by the coeftayl calls.

I hazard a guess that some of the following might be possible:
a) Form parts or a variant of `Eq` just once, and then instantiate more quickly when the input Components's values change.
b) Figure out a way to have the coeftayl results be done symbolically, so as to instantiate a template rather than do its heavy lifting for each set of Component values.

I expect that there are further improvements possible. Alas I'm out of time for this, sorry.

I noticed that if I changed parameter N from 0.5 to 1/2 then the solve step seemed to slow down. Hopefully that is all "above board" and not any hint that your current results are actually slightly suspect.

Here I use the formula as in your picture, with the x- and y-components switched. And so a similar plot can attain.

plots:-display(
  plots:-spacecurve([t*cos(t),t*sin(t),2*sqrt(2)/3*t^(3/2)],t=0..Pi,
                    thickness=4,color=black),
  axes=normal,view=[-3..3,-2..4,-2..8], scaling=constrained,
  orientation=[50,70,0]);

You also mentioned 2D plotting, but that could mean several different things and you haven't explained what you are after. Perhaps a projection of that spacecurve, onto the x-y or some other plane?

Download poly_puzz.mw

The roots are R, and the polynomial is P.

@C_R Notice that your code does not assign the expression to a name, and merely reuse it at the different values of Digits.

Rather, your code explicitly re-forms the expression at the different values of Digits.

The 1e-11 invocation forms the very same float expression at both Digits settings. But the 0.1*10^11 forms different float expressions at those two different values of Digits.

The differing coefficients makes the expressions being passed be to is be different (ie. different address, etc).

That makes the remember table get used for one flavor (where the expression passed is identical) but not the other (where the expression passed is different).

Download flt_ex.mw

On the other hand, if you formed the two expressions just once, up front, then the remembered can interfere (here, consistently).

eval_of_range_in_ln_ac2.mw

So, the cause is that (only) one of those constructions produce identical results at differing Digits.

Your attachment had an invalid Equation blob of XML, just after the "Kronecker Delta" text.

Removing that I get the following, which opens ok in Maple 2022.2.

Lecture_2_notes_ac.mw

ps. Maple 2024 seems to have much less of this kind of problem (and might even be able to itself recover your attachment acceptably...). If your school offers it then I suggest you upgrade.

ps. The Mapleprimes posting editor's toolbar has a green up-arrow that allows on to upload and attach worksheet documents to posts. In future you could use that instead of a 3rd-party download site.

Your code snippet shows the name shift being used both as an optional parameter of F as well as for an equation in each of the lists passed for the Q, vec, and point parameter of F. It seems that you want to be able to pass those independently, when calling F.

You might also want one of those to override the other, ie. either the instances inside the lists, or the separate parameter. I've made a guess as to which that might be, since you haven't really explained your goal. (You should easily be able to switch which might be an override, or instead utilize them wholly separately, and/or assign the values to three different locals, etc.)

Using variants on the code below you should be able to access the shift equations (and their rhs values) specified by each of your Q, vec, or point lists. Accessing each of those simply involves using the eval command.

Eg., inside F, you can do any of,
   eval(':-shift',Q)
   eval(':-shift',vec)
   eval(':-shift',point)

One of your queries here is about how to access the rhs of shift=something when that appears in a list. That was also in a Reply of another recent Question of yours on this site. And I used the same approach above as previously recommended -- 2-argument eval -- the only difference is that now you have different local/param vs global references of the name hanging about.

(Again, you didn't state whether you wanted the separate shift optional parameter of F be subordinate, or an override, or unrelated to those three. I've made a guess, and demonstrated a way in which they could inter-relate. Remove that aspect, if not desired.)

Download param_pr_2.mw

I think that you could make it more clear and explicit what behavior you want an expect here. Showing a representative variety of function calls and corresponding expected results (even if the proc code is not given) is a basic thing. You should be explicit about the functionality you want.

ps. I suggest that you run maplemint on your procedures. I expect that you might find that it reports quite a few cases where global names are being used without protection against having prior values. (Eg. Try to run your example with :-shift assigned a float value at the top-level, and see what breaks, etc, etc.) I've tried to make the above "mint-clean".

pps. I understand that your actual procedures might be too long to include here. But you really ought to at least try to write a shorter proc and example that is self-contained and illustrates your query and runs stand-alone. In this case it wouldn't take long.

You wrote that you wanted to solve the pde numerically, so I'll address that methodology.

In that case you could try setting up that BC with a call to a black-box procedure, by which I mean a procedure that returns the numeric integration result when passed a numeric input, but for which a symbolic function call returns unevaluated.

This technique can also be used for some other flavors of example; ie. the black-box procedure doesn't necessarily involve an integral.

Download pds_bb.mw

That region can be shaded using the plots:-shadebetween command. (There are several other ways, using say plots:-inequal or plots:-implicitplot)

Just for fun, I played with some other options for the overall look&feel. Adust to taste.

shb.mw

See here the response about disabling scrollable rtables.

Disabling that GUI preference seems to have fixed a similar instance of the problem.

Is this the kind of effect that you're after?

(There might be a terser way; I just edited what you had before...)

Download minhthien_ts.mw

I have used Maple 2024.1 below.

You can use fprintf instead of printf, if you want to write to a file.

(please check for typos.)

Download minhthien_latex.mw

Does this behavior get affected/improved if you change the interface(rtablesize) setting?

Does this behaviour get affected/improved if you manage to disable the (new in M2024) so-called scrollable rtable/Matrix/Vector display?

ps. I have changed your Post into a Question.

See the Comparing sum and add section on the ?sum,details Help page.

And also note that the add command has special evaluation rules on its first parameter.

Also, your myfac procedure can be done using mul (or add of the powers), instead of a loop. A symbolic formula for it can also be constructed using the product (or sum) commands.

Here is an explanation of how it was going wrong for you (note the error message's meaning), as well as alternatives mentioned.

Download sum_of_geometric_sequence_ac.mw

Is this more what you're after? (Using Maple 2021.2)

I notice that your 2D Input is actually entered using the sqrt command. So one alternative (to fixing it up after the fact) might be to instead enter those with (...)^(1/2) instead of sqrt(...).

Download latex2_ac.mw