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

@janhardo It's unclear what you're trying to say.

P is a factored product. That's central here. The query hinged on the interpretation of the ellipsis.

The f[i] can be sums (polynomials), but that's not central to the query.

Is this old posting of interest to you?

Just to be clear, that P formula represents a product of terms (and not a sequence).

@dharr I like this approach, as a heuristic, and often try it.

One idea is that evala, trying to get some kind normal/canonical/standard form, will try to rationalize radicals which are explicit multiplicative factors of the denominator.

So if you have a target form that has, say, a numerator which is just some integer, and a denominator which is a product of radicals, then it seems reasonable that simplifcation of the rationalized reciprocal might be a fruitful approach.

A couple of variants on that theme, which also happen to work here. (The last one is lower strength.)

Download Simplify_radical_02_acc.mw

While I often try this as a stage in attacking some problematic example, I find it a little harder to explain, since on the surface it might seem a bit ad hoc to some users.