@C_R It is indeed referenced on the ?solve,details Help page -- one of several by links to ancillary methods/functionality.

@C_R If it's of interest, a related parametric solve call is done quite quickly.

(Done with either assumptions or extra inequality conditions.)

Download inequality_reply_ac.mw

@nl4l1f3 Even without recourse to interpolation, some contour plots can be had.

Afleiding_Euler_knik_met_uitvoer_20240405_accc.mw

Hopefully that might give you some additional ideas about how you might further display the overall situation.

(I didn't attempt animation across, say, A2 values. I also didn't have it store the data for quicker re-use.)

@dharr In Maple 2015.2 plot3d is sometimes passing 1.000000001 instead of 1.0 at the upper end of the ranges. That seems to have been fixed in Maple 2016.2 and onward.

3d_coloring_reply_1_ac.mw

@nl4l1f3 I'm sorry, but it's unclear to me exactly what new things you're trying to accomplish.

I don't understand how you are trying to collate, organize, apportion, or plot the data from four varying parameters.

You could start by clearly explaining the end-goals. If that is plotting then please explain whether you want static plots or animations, and what parameter values would remain fixed at single values while others (on axis[1] and axis[2] say) might take their full sequence of values.

Moreover, there is such a great number of combinations of laying out the data (column-wise) as some parameters are fixed or varying that doing so seems arbitrary -- even if you were to detail it properly.

Sorry again. To me there seems now to be a large gulf between the number of possible requirements and the few hints at details that I have little idea how to proceed.

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