@nitins Where is the original definition of the circuit equation? It should be assigned to eq1, prior to the pertinent subs call.

And where is eq2 defined?

Also, the calls to odeplot(...) won't do anything since the plots package is not being loaded. You could change those to plots:-odeplot(...) , after other corrections.

@Ramakrishnan Your claim is not correct. That font specification affects the sin but not the numeral 30. Try with Courier or Arial, and you can see that the numeral is unaffected.

That is why he followed up, to mention that fact.

And that is why I have now followed up with some alternatives, which do affect the numeral.

@mapleatha Sorry, I was focused on removing the italics, and forgot about your font specification.

You could choose from these, where I would guess that the first might be easiest (while still being programmatically flexible):

plots:-textplot({[4.2,1.9,sin(Typesetting:-mn(cat(30,"°")))]},
                symbol=point,color=black,
                font=["Arial","Bold",25]);

plots:-textplot({[4.2,1.9,Typesetting:-mn("sin(30°)",
                                          mathsize="25",
                                          fontfamily="Arial")]},
                symbol=point,color=black);

plots:-textplot({[4.2,1.9,Typesetting:-mn("sin(30°)",
                                          mathsize="25",bold="true",
                                          fontfamily="Arial")]},
                symbol=point,color=black);

@mmcdara Such automatic pretty-printing of the Logic operators (in output) was introduced in Maple 2017.

It is possible to define printing procedures for &and, etc, for earlier versions such as Maple 2015. But note that such would require extra delimiter round-bracketing, to avoid problems with precedence. And the brackets look ugly when not necessary -- but discerning when necessary could get technically difficult within such a mechanism.

Here is a crude start on such pretty-printing in Maple 2015. As is, it will not get the bracketing correct. naive_log_pr.mw I actually think it's a waste of time to work on this for Maple 2015 as the Copy&Paste or such pretty-printing output doesn't properly work with this in even Maple 2015.2.

Even with interface(typesetting=extended) forced in one's Maple 2015.2 I don't think that the Typesetting:-RuleAssistant can be used successfully and conveniently to get those pretty-printing effects.

Overall, I'd say you're better off relying on your later Maple version, for such pretty-printing effects.

The ability to utilize names beginning with & as infix neutral operators is documented on the neutral Help page.

I have submitted a bug report (ie. SCR, software change request).

@C_R Quite a lot of your last response indicates that you consider ()() as a distinct piece of syntax. But it isn't, really. It is use together of two separate bits of syntax: one pair of parentheses for grouping or delimiting terms that will be applied (like an operator), and a second pair of parentheses that denotes function application (and groups the arguments of that, if any).

Yes, parentheses thus serve two different syntactic purposes here.  Both these purposes of parentheses (grouping or delimiting of terms, or denoting function application) can also be used separately. Yes, you can utilize both together, but it's not a single piece of syntax.

The case of grouping or delimiting expressions (that are to be used as an operator) isn't just useful for composition and arithmetic of the terms. Another important class of example is using parentheses to delimit an expression or an anonymous procedure.

There are currently at least seven examples of using the grouping/delimiting parentheses together with parentheses for function application, on the examples/functionaloperators Help page.

I like your example using parentheses to delimit an equation used in function application. An example such as (f=g)(x) would be useful on that Help page.

ps. I think that whattype isn't highly useful and shouldn't be emphasized as if it were.

pps. Round-bracket parentheses can also denote indexing of rtables.

@rlopez Here are some examples (using row Vectors to render results side-by-side without separating commas). You should be able to see which names in which subscripts are in italic versus upright roman. 

Download subscriptroman.mw

That makesub2 is a little "stronger" than that makesub, as it can handle pretty-printing of some additional compound expressions.

ps. I see only mention of indexed names in the current version of the Question. Did the OP actually ever ask about "subscripted" names? Otherwise, I don't understand why Carl wrote at length here about so-called atomic, subscripted names versus indexed names.

Thank you Carl, that is what I meant (but failed to convey adequately, sorry). A wrapping procedure around the integrand can raise working precision (Digits). In this way the functional evaluations of the integrand can be computed to higher accuracy while the numeric quadrature scheme can still be the externally-compiled/hardware-double-precision NAG function d01ajc (which has some decent handling around singularities).

However I don't quite use the form that Carl showed for the wrapper procedure around the integrand calls, for a reason I'll now try to explain.

@vv Some years ago the evalhf mechanism was enhanced to allow for temporary escape from within a procedure running in/under evalhf-mode. It was also amended to allow Digits to be set within such a procedure. But such a setting of Digits would only affect the temporary "escapes", not the evalhf running of the current proc. (I think that this is a slightly flawed design because I imagine that it can confuse people -- tripping them up into thinking that such a Digits change might affect the running proc itself...)

Here are some examples which I hope will illustrate more. Personally I usually throw in a dummy list reference to forcibly disable evalhf when I really want to be 100% sure I've disabled evalhf-mode under the `evalf/Int` or Optimization or plotting call that I'm testing.

[edit. Extra calls to forget(evalf) might assist insight in some cases, even if it doesn't alter the results... ]

Download evalhf_notes.mw

One of my points is this: when I want to deliberately prevent computation under evalhf (because, say, I'm testing performance and wish to examine the case without it) then I have to take special care to prevent it altogether. Otherwise the "escaped evalhf" business can be a little too tricky for me to know exactly what the control flow and effective working precision has been.

I know that some Optimization/evalf-Int/plotting commands have userinfo messages that indicate which of the evalhf/evalf modes they are using. And some respect UseHardwareFloats=false for the control flow. But those things are no guarantee against implementation bugs. When I want a wrapper that definitely won't work under evalhf, or which is guaranteed to force and utilize some higher working precision, then I make my proc non-evalhf-able. (An exception might be when a no-op list reference confused codegen's gradient. Such fun.)

ps. Yes, I meant to convey that forcing a tolerance through the epsilon option is more careful and robust than passing a small value for the digits option, for evalhf(Int(...)) .

What would you do with such a solution, if say it turned out to involve expressions that took 100 pages to pretty-print?

It's a serious question: what, precisely, are your plans for such a symbolic solution?

@mmcdara It is certainly not true that evalf(Int(...)) cannot be used with Digits>15.

Even the specific method=_d01ajc can be used alongside functional evaluations of the integral that are done at higher-than-double precision (ie. Digits>15 and non-evalhf). But some care is needed for some variants.

It was not clear whether the OP needed values very close to the cusp. The curve cusp can't easily be very well visualized except on a very narrow range of theta, so I am not sure that I understand what the motivation is for doing so.

The OP makes a mistake by applying evalf to A1 and A2 prior to the subsequent integration and plotting. That already incurs numeric error which could skew attempts are doing the integration/plotting at higher working precision. I had removed those early evalf calls, in my Answer. And I have indeed run the whole thing at significantly higher non-hardware precision. So far I haven't detected major inaccuracy for the fast hardware double precision evalhf approach, except so very close the cusp that (IMO) it hardly matters.

But the OP has not provided insight into what he wants from the plot: eg. qualitative insight, or quantitative optimization estimates, or something else...

ps. Your call,
     int(eval(A1+A2,omega=20.099752),theta=0..Pi, numeric, digits=5)
is not the right way to get 5 accurate digits in general, or even to force a coarse tolerance near say 1e-5. Also, one should not rely upon evalhf'ability of the integrand, IMO. More appropriate is to specify the accuracy tolerance explicitly, instead of having it be implied by an unholy low value for the working precision. (I am not sure of the value you obtained for this, btw.)

In future please use the green up-arrow in the Mapleprimes editor to upload and attach your worksheet .mw file.

Providing only an image of your code is unhelpful. Nobody else should have to retype it.

@Carl Love I understand now, you wanted longer subtickmarks. Thanks.

And you don't like multiplying by `°` because the ensuing spacing is too wide. (I think you could get by with `if`(irem(k,4)=0, cat(k*45/4,"°"), "") in Maple 2018/2021, though it's not a great deal terser.)

@Carl Love I'm not sure that I understand why that use of `if` and irem are used. For flexibility? Perhaps more straightforward for the common case might be, say,

plots:-polarplot(phi, phi=0..2*Pi,
                 axis[angular]=[tickmarks=[seq(i*Pi=i*180*`°`,
                                               i=0..2,1/4)],
                                gridlines=[32,majorlines=4]]);

I don't mean this as any kind of criticism.

@Kitonum As Carl mentioned, a mix of both approaches looks nice and it reasonably legible.

And Unit(degree) could be used in the range, instead of using the Pi/180 factor for each occurrence of the variable.

polaraxisdesgrees.mw

This also works in Maple 2018.2,

plots:-polarplot(cos(3*phi*Pi/180), phi=0..360,
                 axis[angular]=[tickmarks=[seq(i=cat(i,"°"),
                                               i=0..360,45)],
                                gridlines=[32,majorlines=4]],
                 angularunit=degrees);

plots:-polarplot(cos(3*phi), phi=0..360*Unit(degree),
                 axis[angular]=[tickmarks=[seq(i=cat(i,"°"),
                                               i=0..360,45)],
                                gridlines=[32,majorlines=4]],
                 angularunit=degrees, labels=["",""]);

@tarik_mohamadi Substituting Bi=1 after simplifying/computing under the assumption Bi>1 seems to me like the kind of thing that can lead to invalid results.