That can be avoided by selecting the symbol (subscript and all), right-clicking, and selecting 2D Math -> Convert To -> Atomic Identifier. You could also select the 'subliteral' symbol in the Layout palette or the `a[n]` symbol in the Expression palette.

I might consider defining the transformations in terms of expressions of functions rather than functions themselves; it makes the code easier to read and eliminates the possibility of the error that had crept in earlier. Thus, the table would be

trans := table(['sin' = tan/sec,
                'cot' = 1/tan,
                'cos' = 1/sec,
                 ...
               ]);

If functions are preferred, one could convert this expression to functions with unapply (as Jacques has pointed out, this doesn't affect the performance because the conversion is done during the build rather than the execution):

trans := table(map(eq -> lhs(eq)=unapply(rhs(eq)(x),x)
                  , ['sin' = tan/sec,
                     'cot' = 1/tan,
                      ...
                    ]));

If wringing every bit of speed out of this conversion were necessary (that seems unlikely here), a conditional approach (if/elif/elif/...), as was originally done, is faster, at least for a small number of choices, than a table-based approach. However, there isn't a nice way to do this and retain the maintainability that the table provided; specifically, there isn't a good way to extract the function names from a conditional. It is unfortunate that we must assign the global name `convert/sectan` to create this conversion. Nicer, I think, would be to have a ConvertTools package, analogous to TypeTools, that exports an AddConversion procedure.

No need to use a plot variable if you are plotting a procedure

f := x -> exp(-x)*sin(x):
plot(f, 0..2*Pi);

No need to use a plot variable if you are plotting a procedure

f := x -> exp(-x)*sin(x):
plot(f, 0..2*Pi);

Try Digits.

Thanks for the correction. Rather than cut and paste, I just retyped the code, but with some typos. Here is what I meant to post

with(numtheory):
cfrac(77/45,'quotients');
                                [1, 1, 2, 2, 6]

cfrac(%[1..-2]); 
                                     12/7

Your method is probably more useful, in that the user can pick the appropriate fraction. Here is the output,

convert(77/45,confrac,cvgts);
                                [1, 1, 2, 2, 6]

cvgts; 
                                               77
                             [1, 2, 5/3, 12/7, --]
                                               45

One could do the following for a quick check of the relative error

map(x -> evalf[3](x/cvgts[-1]-1), cvgts);
                          [-0.416, 0.169, -0.0260, 0.00186, 0.]

Thanks for the correction. Rather than cut and paste, I just retyped the code, but with some typos. Here is what I meant to post

with(numtheory):
cfrac(77/45,'quotients');
                                [1, 1, 2, 2, 6]

cfrac(%[1..-2]); 
                                     12/7

Your method is probably more useful, in that the user can pick the appropriate fraction. Here is the output,

convert(77/45,confrac,cvgts);
                                [1, 1, 2, 2, 6]

cvgts; 
                                               77
                             [1, 2, 5/3, 12/7, --]
                                               45

One could do the following for a quick check of the relative error

map(x -> evalf[3](x/cvgts[-1]-1), cvgts);
                          [-0.416, 0.169, -0.0260, 0.00186, 0.]

I'm never wild about using a float as the index of a loop. If nothing else, the final value will be off slightly from what you want. Better, I feel, to do

[seq(evalf([k*Pi, sin(k*Pi)]), k = 0 .. 1, 1/10)]

Or use an integer index and divide in the list.

It was a joke, and clever at that. Note that Q(0.) = 0 as does Q(x). The :: operator could have been used to prevent premature evaluation with symbols (using piecewise):

Q := x -> piecewise(x::rational,1,0):
int(Q(x), x=0..1);
                   int(piecewise(x::rational,1,0),x = 0 .. 1)
evalf(%);
                    0.

Better would be an explicit test for a numeric, but what's the point.

It was a joke, and clever at that. Note that Q(0.) = 0 as does Q(x). The :: operator could have been used to prevent premature evaluation with symbols (using piecewise):

Q := x -> piecewise(x::rational,1,0):
int(Q(x), x=0..1);
                   int(piecewise(x::rational,1,0),x = 0 .. 1)
evalf(%);
                    0.

Better would be an explicit test for a numeric, but what's the point.

It's listed in the SeeAlso section (of ?list, which actually goes to ?set). Usually it is worthwhile to skim those to see whether anything looks useful. Admittedly 'nops' is not self explanatory, but for something used so frequently, a short name is appreciated.

To get the long bar and form an inert object, first type in the expression, select it, then click the "OverBarOver" in the Accent palette. Then select the expression, with the overbar (by default, the expression will remain selected, but not the overbar), right-click, and select 2D Math -> Convert To -> Atomic Identifier.

To get the long bar and form an inert object, first type in the expression, select it, then click the "OverBarOver" in the Accent palette. Then select the expression, with the overbar (by default, the expression will remain selected, but not the overbar), right-click, and select 2D Math -> Convert To -> Atomic Identifier.

Excellent. So the proper second argument for the seq should be

p = select(type, {anames('user')}, 'procedure')

Okay; I'll have to come up with a useful title. The try statement being straightforward, I originally considered this tip as more suited for inclusion in the Tools for the Reasonably Competent book; however, I think the elimination of the assignment to the inert variable is a nice flourish. I saw that in library code this weekend; previously, I've utilized some ugly hacks to avoid an extra assignment (those tips belong in another wing of the library).