I'd be surprised if there weren't some easier way.

Download Maple_example_ac.mw

I suggest that, with a simple correction to your choice of location, the with(...) package loading should work without having to append to libname either in your session or in an .ini initialization file.

The "toolbox" location can work like that, but the files should go into a "lib" folder that resides under the package-folder. For example,
   "Cliffordlib/lib"
instead just "Cliffordlib", for the bottom-most location of the library archive files.

The first portion you can get/check using the Maple command,
    cat(kernelopts(homedir),"/maple/toolbox")

Then completely close Maple and all its GUI instances. Then relaunch, and tell us whether you can load your package using the with(...) command, but without having to adjust libname at all (either manually in the sesssion, or within an .ini file).

ps. Library archives used to come in a pair of files, eg. "foo.lib" and "foo.ind", but in modern Maple that is done using a single file named "foo.mla". If you don't have the original source files, and if it works ok, then you could just leave it.

There's always room for improvement in the algorithm that selects methods and results. (A real-valued result that's continuous for real x has quite a bit of appeal...)

Download some_integral.mw

The running-icon for my Maple 2026.1 was just a generic gear icon in my Ubuntu 24.04 LTS. I've now solved that issue.

I edited the already existing file from an earlier version's installation,
    /usr/share/applications/maple2024.desktop

I added to that file the line,
    StartupWMClass=com-maplesoft-application-Launcher

Strangely, editing that particular file doesn't make the running-icon be the blue-maple-leaf, for my Maple 2024.2. But it does, if I launch my Maple 2025.2 or Maple 2026.1.

I didn't know what to set the StartupWMClass item to, originally. But then I looked here.

I usually don't bother checking the box to add it to the Desktop, when I install Maple. I'd expect that doing so would get me the basic maple2026.desktop file. And to that I could add the StartupWMClass item (as above) if it were missing.

So now it works properly for my Maple 2026.1 (and Maple2025.2) as well. I simply copied that .desktop file from an older install, and then edited its version numbers, and added the StartupWMClass item which I described above.

How about plotting the absolute difference?

Download testint3_acc.mw

Another way,

sort(sigma+i*t,sigma):

plots:-textplot([2,3,Zeta(sigma+i*t)=Sum(1/n^(sigma+i*t),
                                         n=1..infinity)]);

Is this the kind of thing you're after?

Note that your code part that uses satisfies could be simpler.

Note that also that it's not enforcing strictly two entries in the set. (You did not explain exactly what you want to do. I've got guesses.) Relying on a list element being sorted and put before a Vector element within a set seems like suboptimal coding to me; I'd prefer to specify a list [] of precisely those two typed entries, in such a case.

Download Ronan_TT1.mw

ps. I changed your code's original text TT:-AddType to TypeTools:-AddType

In your Questions original example (and also mentioned in a followup Reply) you tried passing in a list. I'm going to guess that this aspect is something you want in particular, and show a way to use do it while assigning the passed values to locals a,b,c,d.

So, here is one way you can do that, using a single keyword parameter. As Carl mentioned, you could also have four separate keyword parameters for each of a,b,c,d. (Below, my second example re-uses his suggestion, just for comparison of how they both can get used.)

nb. I don't know whether you'd prefer terser source code, or more readily understandable source code, or code that is easier to use, oder...

Download varlist_param_ex.mw

Is this the kind of thing you're after?

Download 2026-08-03_Q_Remove_Common_Factors_from_Matrix_ac.mw

ps. For fun I also added that _nresults bit, so that if you do assign the results of the call to a pair of names (multiple assignment) then the procedure returns both the Matrix and the yanked factor.
pps. I didn't much alter your approach (lcm & gcd, say), but one might...

In order to get one of the relatively more efficient ways of doing it, the precise nature of the structure of the elements of the models should be specified.

Are svars the only non-indexed names that will be present? Is alpha[n,m] the only flavor of indexed name possibly present?

Is each element of a list in models of the form,

   x^i*y^i*z^i*alpha[n,m]
, or a sum of such?

Also, are there very many elements in some of the lists in models, or is there just a very large number of modestly sized lists in models?

Depending on what is the known of the nature of the element structure affects how efficiently the result can be computed, because it affects what generalizations are (un)needed.

You small example might not characterize what kind of elements might be present in the lists in models.

Consider the following variants, which I just concocted to work with your small example. Depending on the restrictions on the structure of the elements, some of these may be faster or slower, and some may work or fail. And I could cook up lots more, many of which would not work ok for examples that break some structural details that I cannot correct deduce from your small example.

It's quite difficult to try and find a good implementation when it's unclear what possible other generalizations might hold for the elements. I think that's important and (IMO) should be obvious.

ps. I might well be a good idea to try and optimize the individual operation that you want to parallelize, up front. Consider the first variant below, which removes from your original one extra user-defined (non-kernel-builtin) proc call for every handled item. Overhead adds up...

Download emendes_exS.mw

I did this with Maple 2026.1 (but it behaves the same in M2015, M2020, and I expect others).

Naturally, in the Maple GUI itself units are rendered in upright roman instead of being enclosed in double-braces.

A variety of test case examples, and programmatic usage:
[note: edited, to adjust for another special case example]

Download unit_unit_2.mw

So, you have seen this page, then?

What does the GUI ribbon tab "My Maple" look like for you? Mine looks like this:

If I click on the "Maple MCP" icon in that image, I get a popup that contains a copyable "Access Code", as well as a URL link. If I click on that link then it takes me to this Maplesoft page.

I didn't follow all the instructions on that page, but I'd be interested to hear what success you might have with this path.

You piecewise's first condition implies that if t is greater than 0 then the returned value is 0.

And that's what you get, since for x=0..1 all the x values are greater than 0 and the evaluations all become 0 (zero). The curve is the flat line at height zero. If you added option thickness=5 then you'd see it more clearly. It's not an empty plot, it's just a line that is all zero in height.

Perhaps you intended some different first condition (eg. t<0), or some different range (eg. t=-1..1).

The call to dsolve is running with its userinfo statements activated by your infolevel[dsolve]:=5 .

The muddle with the Equation Labels (appearing beside the userinfo messages, which shouldn't happen at all, let alone with repeated values, IMO) appears to be triggered by the appearance of output from the 2nd Execution Group in that same Document Block, which is present after the 1st Execution Group that contains that dsolve call.

In other words, if you move the,
   DEtools:-odeadvisor(ode[1])
into a new, separate Document Block then the muddle seems to clear up.

I don't think that this is a new issue. I seemed to be able to recreated it in, say, Maple 2020.2.

nb. I have Annotation Markers toggled as visible, under View from the ribbon. That lets be see where the Document Block boundaries lie.

This seems like a bug to report.

If you only need to plot it then the tolerance for the numeric integration doesn't need to be super fine.

For some ostensbily complex expressions, simplify@evalc might produce en enormous new expression, or take a very long time. Since your integrand1 and integrand3 are quite short, maybe the numeric roundoff is acceptable.

Download heat_equation_on_finte_interval_ac2.mw