Here is a revision of the worksheet that threw an error for the OP in Maple 2023.

The problem was that using op on the expression containing a piecewise is not robust. Having some extra multiplicative factors outside the piecewise can break the well-meaning op calls. The symbolic integration can differ in form slightly between versions (while still being correct).

You could combine the factors into the piecewise (see attached). Better still you could use the conditions of your conditional to reduce the piecewise to the corresponding values (see attached).

ps. If you want the proc to return unevaluated when the argument passed is not numeric then you should return quoted 'procname'(...) instead. Your return of procname(...) throws a recursion error if f_U gets called with a non-numeric argument. The reason you didn't get such is that you only used it within seq which has special-evaluation rules.

PDFDerivation_ac_M2023.mw

No, please don't spawn a separate Question thread to ask how to get this code to run in a newer version.

I'll try to adjust it, and get back to you here.

Could you use ImageTools:-Scale on it, so first get it to a suitable size? Does it contain text that would be trickier to scale?

Could you provide an example of such a .png file?

We don't know how you created it, but perhaps you could initially create it as larger size.

@C_R Ok, your last response was posted just before my last. I think it shows I finally understood where you were starting from.

And so you could just use the replacement,

   varphi__0 = `#msub(mi("varphi"),mn("0"));`

instead of,

   varphi__0 = varphi[0]

that you might have previously set up. Eg,

Download Evaluation_of_elliptic_integrals_ac4.mw

As for your query about why the indexed name is a problem: The variable of integration is itself varphi, and the situation muddled and sometimes ambiguous if an indexed instance of that name is also present. It's a logical collision. The value one of the names depends on any running value of the other. And the meaning can be quite unclear. One can find many previous postings here about why one should not mix the main variable and indexed instances of it in calls to solve, int, dsolve, etc, etc. IMO it's not just the parsing that may be unclear; the very meaning can sometimes be unclear. So, don't mix a base name and indexed instances of it.

The bit of double indexing that you find mysterious is because of the mix of the name of integration and indexed instance of it. The problem being sent in to int, with the mix, is not well-defined. Garbage in, garbage out. At some point int will have to replace instances of the variable of integration, and those substitutions can produce nonsense if the replacement occurs on the base part of an already indexed name.

It occurs to me that your scenario might be one in which you start off with the expressions having the double-underscore name varphi__0, and want to only see the rendered subscript with upright Roman.

So, a similar replacement can work, and you can construct the replacement directly or programmatically. And here indexed names are not involved.

And, again, if you have just the single name to handle then it'd be simpler to just use the directly constructed replacement,

     L := { varphi__0 = `#msub(mi("varphi"),mn("0"));` }

Download Evaluation_of_elliptic_integrals_accc.mw

Here is another example of an indexed name, for which double-underscore doesn't look so great.

It's just a simpler kind of temporary replacement...

Download Evaluation_of_elliptic_integrals_acc.mw

@lemelinm You could also get that new list of equations, T, with,

    T:=(u->u=GetValue(Constant(u))*GetUnit(Constant(u)))~(L)

@Motocycle Mayor Perhaps when you saw the problematic behavior you had inadvertantly done a restart, or tried after only re-opening the Document.

@TechnicalSupport Fwiw the OP's original attachment shows that it was last saved in Maple 2025.1, so presumably that's the version he was using.

I changed your Post into a Question.

Please submit your future queries as Questions.

@Motocycle Mayor Thank you.

Your Document runs ok and as expected in my Maple 2024.2.

Ribbiting_Disparities_29_ac_2024.2.mw

I'll have to get back to you about Maple 2025.1, unless someone else clarifies sooner.

ps. The line,
   with DataFrames
doesn't do anything or load anything. It's just a product of two names. It shouldn't hurt, though.

@Geoff For that alternate input,

Download Groupings_ac4.mw

@Geoff Change the type specification of the L parameter (in the definition of procedure Groupings) to L::list instead, so it'll look like,

   Groupings := proc(L::list, k::posint)
      ...
   end proc:

@Motocycle Mayor A reasonable first step would be to attach an Excel data file that could be used with your Import command and which creates a representative example that reproduces the problem.

Uploading and attaching an Excel file and .mw Maple worksheet that can be used together to reproduce the problem is often a very good first step here.

In the absence of an actual worksheet it is more difficult for me to determine the cause, eg. whether Data is actually a DataFrame, etc.

Mentioning your Maple version (or marking it in the field at the top of your Question) might also be useful. Are you still using Maple 2019?

Could you please attach an Excel data file and the Import command which creates a representative example that illustrates the problem? You can use the green up-arrow in the Reply editor, to upload and insert links to files.

Are you sure that the entries of the column are all strings already? Have you tried,

   SubsDatatype(Data, "UN Region", string, conversion=String );