@Son Ho Did you trying using the indexed form, D[b] ?

You can also enter that form, already as subscript, in 2D Input, eg., on my Linux,
    D Ctl-Shift-underscore b

@C_R He didn't remove elements of type list. That is, he didn't do this:

r := [[5,7],[],[1,3],[],[5,4]]:

remove(type,r,list);

         []

Rather, he used a structured type, [].  Note that type(...,list) and type(...,[]) are not the same.

One could also leverage type,list  (with that aspect being unnecessary if we already know it's a list of lists),

remove(type,r,And(list, 0 &under nops));

     [[5, 7], [1, 3], [5, 4]]

remove(type, r, 0 &under nops);

     [[5, 7], [1, 3], [5, 4]]

# See also nm's Answer
remove(L->nops(L)=0, r);

     [[5, 7], [1, 3], [5, 4]]

Also possible is the following (straightforward IMO),

  remove(`=`,r,[])

That example does not cause a crash in my stock Maple 2024.0 for Linux, running without any Physics update.

It seems doubtful that your crash here is caused by the very same thing as that previous report you've cited.  That was crashed in the conversion of a high degree rational polynomial to parfrac, and the crash was reproducible entirely outside of any int call.

I'm curious about one thing though. Does it crash if you force only method=contour?

Using Maple 2023,

Download Aung_1_ac.mw

By the way, you used lowercase pi (which means nothing to Maple) instead of Pi.

@C_R The is no indexed procedure here.

There are indexed names here, but nothing's assigned to such here. (It's not a table-based package.)

Some procedure got assigned to a symbol such as foo.

Then the indexed name foo[bar] was used in a function call, eg. foo[bar](x). I personally call that an indexed procedure call, if prompted to call it something other than just a procedure call.

Nothing's stored in a table here. Nothing's assigned to the indexed name.

@C_R

The form,
   foo[name]
is another way that the form,
   foo/name
and,
   foo,name
can generally be used as the Topic name for queries in the Help system.

Nowadays most Help Topics are in the form foo,bar.  But foo/bar and foo[bar] also work as searchable terms, for backwards compatibility.

For example, there is no command int[details], but if you query that in the Help system it'll open the Help page for Topic int,details.

Having said that, the cross-reference Help labels like simplify[size] are just confusing and (IMO) wrong and misplaced. It's not a module-based package like Student, nor a table-based package like inttrans, and those indices are not members of any simplify package.

I shall submit a bug report about those cross-reference labels in the documentation. The least confusing thing to have for those (IMO) would be cross-references that look like,
    simplify,sqrt
    simplify,trig
etc.

Two of the biggest sources of problems in Maple are,
1) allowing two different bits of syntax/structure to mean/represent the same thing
2) having one syntax/structure mean/represent more than a single thing

@C_R In your previous Question (also about indexed procedure calls) my Answer made use of op(1,procname) .

I considered mentioning that you might also add various guards, defensive programming, further manipulation of procname, etc, to that.

When you call  f[a,b,c](...)  then inside f a reference to procname will evaluate to all of the indexed name f[a,b,c].

And you can poke at that just like any other indexed name. Using op you can get its operands. Using op(0,procname) you can get the base name f. And the usual type checks for names can be utilized, as Preben's shown above.

Download procname_ex.mw

[Sorry, I had to do a chore, and split my response.]

The Help page ?simplify,details has a table of links, in its Options section.

The text labels of those links are names of some options that the simplify command admits.

The links go to Help pages whose Topics are available in the Help system in the form simplify/name, where name is one of those labelled options. There are actually procedures assigned to most of those, eg,
   showstat(`simplify/sqrt`);
   showstat(`simplify/piecewise`);
That Help page ?simplify,details describes them as "simplification procedures" because 1) most are such, and 2) internally simplify's implementation of its approaches is organized by procedures.

So, the internal mechanisms corresponding to the various options of simplify are mostly organized by procedures with a naming convention similar to the option names. I suspect that this is the key thing that you hadn't realized.

Note 0: I don't know how you came up with the syntax simplify[sqrt] or combine[trig].

Note 1: One reason for the that (old) internal naming convention involving "/" is kind of historical. A long time ago it was also quite usual for the some names of ancillary (internal) procedures and of the Topic of some Help pages to be split by "/". That was partly due to the way that source code was stored in directories by Maplesoft, in Unix.

Note 2: Several kernel builtin commands allow for an extension mechanism that also relies on the form,  `foo/name` . So, there's some more historical convention...  But Library commands don't automatically allow for such; The simplify command's Library code is written to call those mentioned `simplify/name` procedures when it sees fit. Moreover,

restart;
`simplify/f` := proc() K(args); end proc:
simplify( f(A+b, C+G) );

      K(f(A + b, C + G))

See showstat(`simplify/do`,74..89) where parts of that mechanism is coded for simplify.  My point here is just that its extension mechanism implementation -- using `simplify/name` -- also happens to be consistent with its naming convention for its "simplification procedures" that match option names.

I shall be submitting a bug report that dsolve,numeric does not directly recognize an appliable object (such as Interpolation returns) for use with its known option.

@dglevitt I described it as an option of the dsolve command.

Since dsolve,numeric is the command/topic that was with which you were having issues, its Help page is a decent place to start looking. (One wouldn't search for "known" if one didn't yet know anything about it or of its existence.)

You can find a description and examples (eg. for the known option at the end, for dsol8, dsol8b) on the Help page for the dsolve,numeric command.

@C_R Your syntax,

E := t -> Mt(t);
diffeq := D(C)(t) = E;

is muddled. Utilizing the ensuing "solution" from dsolve in odeplot will not actually make any calls to E. You'd get similar invalid results with, say,

Q := z->0:
diffeq2 := D(C)(t) = Q;

Also, could you please show how your remarks about derivatives of a linear interpolant come into play with this particular result from LinearInterpolation? (We know that we could simply get by with 3*t instead, but that's quite another issue.) How does your claim explicitly come into play with this returned Interpolation object? Or perhaps you were writing more generally, say of piecewise linear examples where the derivative might agree in limit on only one side of each data point?

@Rouben Rostamian  That would get get it down to 3 times. His code also called his procedure three times unnecessarily.

It seems to me that the OP is trying to learn how to code better in Maple.

@Rouben Rostamian  If only those changes are made to the original code then it will (unnecessarily) call operator fun nine times with the same arguments.

Those multiple occurrences of `>` within a single execution group have little to no effect.

They are mostly just artfefacts of how multiple execution groups might have been joined (with the F4 key, say).

The name t in your passed equations DV1,DV2 is not the same as the local t declared and used in your procedure.

ps. I changed both this and your previous query from a Post to a Question. Could you please submit future queries as Questions rather than Posts?

If you're going to submit further queries on this same topic then could you please either 1) use the Branch to split them off the earlier one (which automatically inserts cross-reference links, or 2) just add the close followup as Comment/Reply in the earlier thread?