@emendes Below, A2 construction (mine, without indets use) seems to be done faster than everything else except A5.

And A5 construction uses Threads:-Map with indets. But it might be the case that the thread-unsafeness of indets relates only (maybe) to its use on expressions of different nature than yours. I mean, perhaps the thread-unsafeness of indets depends on some aspect of the expression type -- rather than only to the way indets itself it coded. Maybe(?) it is safe on your examples.

Download emendes_exS3.mw

I note also that your original is itself much faster with map than it is with Grid:-Map. I'll just stop timing that approach, below.

For an even larger number of lists in models, it removes some overhead if the procedure,
    v->ifelse(v::`+`,op(map([op],[op(v)])),[op(v/content(v))])
is pulled out of the middle mapped operator. At a smaller number its effect is less obvious.   emendes_exS3b.mw

Here's 10^6 such entries in models.

Download emendes_exS3_6.mw

And here's that, for 10^7.

Download emendes_exS3_7.mw

The timings grow by more than a factor of ten, for ten times as many elements. I suspect that garbage-collection may be taking its toll. I don't see a clear way to reduce garbage production in these approaches.

ps. Can the same alpha[n,m] appear twice in one of the sums, eg,
       x*z^2*alpha[3, 19] + z^3*alpha[3, 19]]
? If not then a call to content might be removed.

@emendes That's great, thanks.

I suspect that something fast can be cooked up, and without using indets. (...a bit like my variant above that didn't use indets, but likely faster as there is more structural detail known now.)

Gosh, even that 11pt (MS-Windows?) looks too heavy, to me.

Here's how it looks on my Ubuntu 24.04.4 LTS, in Maple 2026.1, without any Style-set use. This is a screenshot.

The size in this screenshot is not accurate, compared to what I see in the Maple GUI (which is actually good, for the 11pt non-bold). The ratio of the size of the 2D Input to that of the 11pt text is accurate. 

The weighting shown in this image is an accurate comparison to what I see in the product (which is actually good, for the 11pt non-bold).

Text_Linux_20261.mw

For fun,

Download old_externsion_mech_ex2.mw

@C_R The way that the kernel determines that the extension procedure (user-written) exists, and passes to it, is in the kernel and not visible (if that's what you mean).

Note that your,

`value/__K`:=ex->op(ex):

would not be correct here, since (as mentioned) `value/__K` receives argument s when the kernel sees value(__K(s)) and then calls `value/__K`(s) .

By that I mean that the kernel uses the user-written `value/__K` for dealing with separate function calls of __K, whereever present as subexpressions in the expression. It gets applied separately to indets of type specfunc(__K) in the expression, when value is called on the expression.

expr := __K( sin(4*p) ) + __K( cos(3*t) ):

`value/__K` := ex->op(ex):
value(expr);

              4 p + 3 t

`value/__K` := ex->ex:
value(expr);

          sin(4 p) + cos(3 t)

@C_R Yes, the idea was to hide (temporarily freeze) products where at least one of the multiplicands was a Units:-Unit call and there were other multiplicands than just -1.

Some parts of the code may seem unnecessarily general, because I wasn't sure when I started where it would end up.

When an extension like `value/F` is created as a procedure, then it will get used for dealing with calls like
    value( F(...) )
I suppose that the designers of this mechanism thought that they might as well only pass the arguments of the F(...) call on to this new procedure.  Eg, value(F(s*t)) gets just the agument s*t passed into `value/F`.  So in my usage value(__K(s)) is just returning the argument, here just s.

@FDS_ERT That seems like a workable idea.

I created the attached Workbook, and then attached the data.xlsx file into it using the Navigator in the Workbook view in the left-panel.

I accessed it from the worksheet within the workbook using the following syntax:

   dat := ExcelTools:-Import("this://data.xlsx");

I zipped up the imp_test.maple file just because this site doesn't always deal well with files with ".maple" file-name extension.

imp_test.zip

The basic idea is that a Workbook can contain a Worksheet/Document part as well as additional files, ie. they are carried entirely within it. And such additional files may be referenced and accessed programmatically from with the worksheet part.

When the attached Workbook file (.maple extension) is opened using the Maple GUI (File->Open) then the GUI shows the worksheet part, which appears as usual.

What happens if you put,

    Units:-UseUnit(J/kg/K):

at the start of your session?

Does that alter what you get from your call to GetUnit? (In either of your two Maple versions available?)

@erik10 

I believe that your best course of action would be to contact Maplesoft Customer Service directly, to figure out your EMP status, etc.

https://www.maplesoft.com/contact/index.aspx

I'll add that the changes mention by dharr will affect the input mode in Execution Groups in a Worksheet.

It sounds as if this user wants to use 1-D input in a Worksheet (and not a Document, where it's slightly trickier to get to 1-D because you have to insert an Execution Group).

To change the default format for File -> New items you can go to that same File -> options popup menu, and in its Interface tab change "Default format for new worksheets" from "Document" to "Worksheet".

If you make this change, as well as the change dharr suggested, then your new sheets should be Worksheets, with red plaintext Maple Notation input mode, by default.

Closing the popup menu by pressing the Apply Globally button makes it take effect for new sessions, by default. This is likely what this used wants. (Apply to Session will only affect the current session, so would not affect any other session in the future. Likely not what is wanted here.

ps. When I upgrade my Maple version the installer usually notices an older GUI Preferences file, and asked me whether I'd like to use it for default setting in my new installation. That's how I get my 1D Input + Worksheet settings imported automatically when I upgrade. Perhaps that didn't work out for this user.

@C_R Some of the internals of dsolve utilize remember tables or a cache, which avoids duplicate re-computation if the call to the command is repeated.

Some of that affects some of the userinfo messages (since some of those userinfo calls are made underneath such an internal entry point).

Note that your Document doesn't begin with a restart, so if you re-run it without restarting via the ribbon then some or the computations are memoized.

@C_R 

• open https://www.mapleprimes.com/view.aspx?sf=243654_question/repeated_equation_labels.mw
• insert a new document block after DEtools:-odeadvisor(ode[1])
• cut/paste DEtools:-odeadvisor(ode[1]) into new document block
• either execute the whole worksheet from its beginning using the !!! from the Home tab in the ribbon,
  or Remove Output from Worksheet and then execute it from the start line-by-line

with Maple 2025 and 2026 performed

repeated_equation_labels_-_after_moving_odeadvisor_command.mw

Executing the two statements in the 1st Exec Group in the problematic Document Block, before removing the 2nd Exec Group doesn't seem like an effort to avoid the problem. It's not something that I suggested in my earlier response.

And we already knew how to reproduce the problem! Just execute the original, without cut&pasting anything! Showing another way to reproduce the problem (which happens to only kinda/sorta/almost look something hazily like what I actually suggested) really isn't a highly meaningful response to my suggestion of that it can in fact be avoided. Since I didn't suggest your particular steps, they don't contradict that my suggestion -- if done as I did it -- avoids the issue. There are milllions of small edits of your original that will also behave the same as your original; they don't add too much value here.

@C_R Could you attach (but not inline) that edit? Thanks.

@C_R [The text has since been edited, to clarify the goal.]

This new Question thread duplicates the essential topic of an earlier Question, and is posted as a wholly separate new Question thread. It would have been better to utilize the "Branch" button off of the original Question, so that this would branch off the original and both Questions would automatically get cross-reference links.

[edited]

The Question text has been edited. The original language suggested a desire to demonstrate that two expressions match, which I interpreted as a desire to demonstrate mathematical equivalence.

The new language suggests, rather, a desire for transformation from one given form into another specific form. And, naturally, that's fine as a goal. (It just happens to be different that the original suggested.)