The first of these can be made more programmatic (if an example's scales differ from this, etc).

Download bode_fun.mw

Why not directly pass in the extra inequalities, as part of the set of conditions, rather than supplying them as assumptions?

It's possible that if you specify, say, R__1 < R[c] as an assumption then the result might tacitly include/imply that. (I didn't see clarification on that aspect in documentation.)

Download PlotsInequal_vs_SolveParametric_ac2015.mw

You could create a Paragraph Style Set (adjusted to use your choice for text and 2D Input, say), and then use that as your default.

You could also make those adjustments be the default for a new (otherwise empty) Document/Worksheet, and set that as your default Start Page when opening a New Document/Worksheet.

Several entities can be inserted typeset for 2D Input by using command-completion, even if they are not directly available already in any of the Palettes.

Download cmd_cmpl_ex.mw

In addition, you could produce just the `&cong;` as 2D-Input, and then select it with the left mouse-button, then use the right-click menu to convert it to "Atomic Variable", and then hit Enter so as to get that as output. The output could then be selected with the mouse and dragged into the Favorites palette. You could also do this for other entities, such as `&rarr;`, etc. And you just wanted to add them to the Favorites palette then you could also enter them in that plaintext input form, and drag their outputs similarly. You can find lists of HTML entities in several places, by web search.

There was a time when some of the names used for structured types were not protected. Ie, you could assign values to them, in which case type-checks involving them would break if you didn't prevent evauation with uneval-quotes (single right-ticks).

So it was commonplace to use 'specfunc', etc, quoted.

Some people like quoting the whole call, eg, 'specfunc(blah, foo)' even when it's not necessary and 'specfunc'(blah,foo) would do fine.

I dislike the first of those, because it's not carefully targeted. Your example is one where it goes awry, because it prevents the reference to the assigned local name y from evaluating.

I wish that the Help pages were more discriminating/targeted in use of quotes, vs merely blanket quoting.

Download delayed_vs_not.mw

The global name specfunc is protected in current versions (you can't assign to it), and there you don't need to quote it.

Here's a closer analog of your problematic example's issue, but done outside any procedure. You need indets to be able to see the assigned value of s. Note that your two original examples did not have a similar nature, even aside from one being in a procedure. The reason that they behaved differently is that in the procedure example you'd assigned something to the name used within the specfunc call. If you do that kind of similar thing outside of a procedure then it too would fail. (Your procedure's local and the expression's global were both named y, which perhaps made this key aspect about assignment less apparent to you.)

s := y;

            s := y

type( y(x), 'specfunc(s)' );

            false

type( y(x), 'specfunc'(s) );

            true

In your code's comments you wrote "same code fail". But it was not the same. In the failing procedure version you made an assignment and attempted to utilize it within the quoted portion. In your original failing procedure example the local named y could be also named something else, with identical failing behavior. Ie, here, indets does not receive something containing the value assigned to s, due to the overwide quoting. It's equivalent to your failing example.

In summary, what made your problematic example fail was not that it was the same code done inside a procedure. It failed because it was not the same code -- the name referenced inside the wide quotes was additionally assigned.

By the way, only some of the special names used for structured types are protected. In Maple 2024.2, for example,

Download types_prot.mw

You should (ideally) uneval-quote the ones which are not protected, to avoid problems if any such are ever later assigned. You can pretty much quote them all (and so avoid having to remember which...), if you place quotes around just the name and not some whole bracketed function-call.

An example with some exclusion,

Download type_D_fun.mw

You could tweak that Not type for the exclusion, but I'm not sure what other examples you might have.

nb. Note the use of the uneval-quotes around ':-De', to avoid a clash if that name has been assigned. And the best way in general is also to reference it with the colon-minus, ie. ':-De' because it might be declared local.

For r=3 you can look at 1-1/r=2/3.

And,

Download lmap_fun.mw

You wrote "output", and it's not clear what you need. The above are exact values.

Are you asking for a reference? You could look at section 2 (or section 4, equation 14) of the PDF file here.

I suppose that there are several ways to get the plot, depending on which coordinate systems you'd rather use.

Download 3dplotfun.mw

The ImageTools:-Preview command uses a 3D plot and puts the image data on a flat plane and shows it oriented head-on, so that it looks like a flat 2D image.

The ImageTools:-Embed command embeds an image (as a GUI construct) into a so-called Task region, which as you've noticed always gets shown after the usual output portion of an Execution Group or Document Block (paragraph).

But since the ImageTools:-Preview command was devised, 2D plots got the ability to use an image with the background option. The resulting file is quite large when saved, but you might be OK with it scaled even smaller than 500 pixels wide.

Download img_bg.mw

Using only uneval-quotes (ie, single right-ticks) here is not a robust way to prevent evaluation if you need to pass the expression (or a structure containing it) around in additional command/procedure calls.

The subsequent evaluations that occur for arguments of procedure calls will strip off uneval quotes, and produce the effect you're trying to avoid.

Instead, you could use an inert representation of the expression.

Download undesired_textplot_format_ac.mw

Is this the kind of effect you're after?

[note: Here I'm starting with the problematic indexed name being present.]

(It could be tweaked/adjusted... I don't know the extent of the kinds of indexes you'd need handled, etc. There are even much simpler/shorter ways, if you only want to handle names indexed by posint, etc.)

Download Evaluation_of_elliptic_integrals_ac.mw

If you just need to handle this one single indexed name, then here is an easier substitution, ie. directly constructed:

Of course, if you only needed a single substitution for varphi[0] then you might as well use,

    varphi[0] = varphi__0

which is of course easier still(!) and which you already know to work OK. I wrote you the earlier code so that the approach might be used for more complicated subscripted expressions or situations (for which a mere double-underscore could not suffice), programmatically. I don't know your full scenario(s).

Is this not fundamentally similar to your Question of Sept 2nd?

Download why_dsolve_cant_solve_ode_oct_4_2025_maple_ac.mw

I prefer the eval(..,..) way, and the thing you've actually requested is not a great approach IMO.

nb. One way to cause yourself grief is to re-order L, in which case your request can still be done, but in a different way(!) and with consequences that might be awkward for you. IMO this is a hint that it's not a good idea.

Download Using_the_constants_ac.mw

When you issue,

   Physics:-Setup(assumingusesAssume = true)

the routine `convert/diff` is replaced. And your example's simplify call tries to do,

   convert( (D@@2)(y)(Pi), diff )

which then invokes `convert/diff`.

The replaced `convert/diff` procedure calls,

    Physics:-usepdiff

and (eventually) that causes a call like,

    Physics:-`usegdiff/subD`( (D@@2)(y)(Pi) )

which at one point treats Pi as if it were a variable (non-constant name)

It looks like the snippet,
    Df::'function(name)'
might be better as,
    Df::'function(And(name,Not(constant)))'
in the following Library code,

showstat(Physics::`usegdiff/subD`,1)

`usegdiff/subD` := proc(Df)
local D0, D00, D000, f, z, z2;
   1   if Df::':-`*`' and op(1,Df) = -1 then
           ...
       elif not Df::'function(name)' or Df::'function' and nops({op(Df)})
         < nops(Df) then
           ...
       else
           ...
       end if
end proc

The following example also goes wrong,

restart:
with(Physics):

convert((D@@2)(y)(Pi), diff);
Error, (in unknown) invalid input: diff received Pi, which is not valid for its 2nd argument

Perhaps I can make a hot-edit...

[edit] Well, the following appears to work, but ONLY if the first line conditional of the routine is exactly as it is in my Maple 2024.2. So -- like most such hot-fixes -- it won't be good if the routine has been otherwise changed in that respect.

I would guess that Edgardo or Austin might well fix it in the right/safer way, as part of the Physics Updates, if they see this post or if the pronlem is reported.

Download dodgy_hot.mw

The hang (in Maple 2024 at least), seems to depend on having both 

   with(Physics):

and that,

   PDEtools:-undeclare(...):

In fact it seems related just to the 2D prettyprinting of the constructed partial derivatives within the Vx Matrix result under default extended typesetting (and that loaded environment).

(You can check that claim by suppressing the relevant output by making the problematic line end with a full colon as statement terminator. You can also lprint it.)

So, one workaround is to not make that undeclare call. 

I didn't check whether the latest Physics update add-on the Maple 2024 fixes it.

Here is a shorter example that illustrates the hang (which can be avoided with several kinds of workaround...),

Download derivativve_ex01.mw