f := log(2-cos(x)+sqrt(3+cos(x)*(cos(x)-4))):
R := (1/Pi)*integrate((1-exp(-abs(n)*f)*cos(p*x))/sinh(f),x = 0..Pi):
r := unapply(R,n,p):
r(1,3);
                                  46/3 - 4 Pi
                                  -----------
                                      Pi

r(2,5);
                                  2236   97 Pi
                                - ---- + -----
                                   15      2
                                --------------
                                      Pi

A more interesting challenge is solving the summation that gives the expression for f.  That was the first task to which I applied Maple (Maple V R2, I believe).  Must be an electrical engineering thing...

Is the type assertion of the return value intentional?  That is really strange, and I haven't figured out why it doesn't generate an error (with kernelopts(assertlevel=2)).  I could understand

f := proc(s) :: set; combinat:-powerset(s); end proc:

but how can a set have the type 'type(s,set)'?  That makes no sense, it seems equivalent to doing

type({{},{a}}, 'type'({a},set))

postpost:

I now understand what is going on.  The return assertion `type(s,set)' is, indeed, equivalent to

ASSERT(type(output, 'type'(s,set)))

assuming output is the returned value.  So the assertion, which must be true to avoid an error, is that

type(output, 'type'(s,set))

Maple's 'type' type ignores arguments (s and set) and interprets this as

type(output, 'type')

That is, it is true whenever the output is a valid type.  I had only tested the procedure with a set of integers.  The generate output from that is a set of sets of integers, which is a valid Maple type.

type({{},{1},{1,2}}, 'type');
                                              true

If a symbol is included, then the resulting powerset is not a valid Maple type, and an error is generated:

kernelopts(assertlevel=2):
f := proc(s) :: type(s,set); combinat:-powerset(s); end proc:
f({1,a});
Error, (in f) assertion failed: f expects its return value to be of type
type({1, a},set), but computed {{}, {1}, {a}, {1, a}}

Is the type assertion of the return value intentional?  That is really strange, and I haven't figured out why it doesn't generate an error (with kernelopts(assertlevel=2)).  I could understand

f := proc(s) :: set; combinat:-powerset(s); end proc:

but how can a set have the type 'type(s,set)'?  That makes no sense, it seems equivalent to doing

type({{},{a}}, 'type'({a},set))

postpost:

I now understand what is going on.  The return assertion `type(s,set)' is, indeed, equivalent to

ASSERT(type(output, 'type'(s,set)))

assuming output is the returned value.  So the assertion, which must be true to avoid an error, is that

type(output, 'type'(s,set))

Maple's 'type' type ignores arguments (s and set) and interprets this as

type(output, 'type')

That is, it is true whenever the output is a valid type.  I had only tested the procedure with a set of integers.  The generate output from that is a set of sets of integers, which is a valid Maple type.

type({{},{1},{1,2}}, 'type');
                                              true

If a symbol is included, then the resulting powerset is not a valid Maple type, and an error is generated:

kernelopts(assertlevel=2):
f := proc(s) :: type(s,set); combinat:-powerset(s); end proc:
f({1,a});
Error, (in f) assertion failed: f expects its return value to be of type
type({1, a},set), but computed {{}, {1}, {a}, {1, a}}

It's in my reply, but I used b, not c.  If you can't understand the output, try running the maple commands.

It's in my reply, but I used b, not c.  If you can't understand the output, try running the maple commands.

What is a formal definition of odevity?  I'm unfamilar with the term, and a google search was not conclusive. Can it mean more than just being even or odd?

What is a formal definition of odevity?  I'm unfamilar with the term, and a google search was not conclusive. Can it mean more than just being even or odd?

An alternate approach is to pass procedures rather than expressions to plot.  For example,

plot(map2(curry,T,[$1..5]),0..Pi);

Possibly a nicer approach is the following

T := (nk,theta) -> 2*cos((theta+beta)/2) + theta/nk:
plots[animate](plot, [curry(T,nk),0..Pi], nk=1..3);

I had already tried that.  As jakubi notes, it doesn't work.

I had already tried that.  As jakubi notes, it doesn't work.

A different approach is the following

TypeTools:-AddType('propexpr'
                   , proc(ex)
                         try
                             assume(subsindets(ex, 'And(name,Not(constant))', rcurry(convert,`local`)));
                             true;
                         catch:
                             false;
                         end try;
                     end proc
                  ):

It calls assume with ex and returns true if no error was raised, otherwise false. The subsindets is an attempt to prevent assigning assumptions to variables you care about.  I'm not wild about this (don't like calling assume), but you can play with it.  Note that type/type works this way (traps error to detect non-types). 

A different approach is the following

TypeTools:-AddType('propexpr'
                   , proc(ex)
                         try
                             assume(subsindets(ex, 'And(name,Not(constant))', rcurry(convert,`local`)));
                             true;
                         catch:
                             false;
                         end try;
                     end proc
                  ):

It calls assume with ex and returns true if no error was raised, otherwise false. The subsindets is an attempt to prevent assigning assumptions to variables you care about.  I'm not wild about this (don't like calling assume), but you can play with it.  Note that type/type works this way (traps error to detect non-types). 

We used to get an email notification when someone responded to a thread to which we are subscribed, which was usually any thread we had contributed to.  That is, apparently, no longer the case.  What I do is check the "Recent posts" link on the upper left of the page every once in a while.

(2) only shows that an antiderivative exists on any closed interval, which isn't quite the same as showing that a continuous function has an antiderivative everywhere it is defined (though the problem statement wasn't that specific).  It shouldn't be hard to patch this up.

(2) only shows that an antiderivative exists on any closed interval, which isn't quite the same as showing that a continuous function has an antiderivative everywhere it is defined (though the problem statement wasn't that specific).  It shouldn't be hard to patch this up.