@hirnyk 

A nicer way (equivalent, just less typing) to input your solution with diffs is

vars := indets(T,name):
eqs := map2(diff,T,vars):
fsolve(eqs);

It might be useful to show how the reevaluation can be avoided without creating a procedure.  That can be accomplished with the two-argument form of the the ?eval command. Here the second argument is the integer 1, which tells eval to evaluate the first argument one time. So the type check would be

  type(eval(res,1), numeric)

Generally I find it convenient to write procedures even for one-off computations. Not only do you get the automatic speed-up from one-level evaluation, but, if the code is slow, it is easy to use the ?CodeTools[Profiling] package to find the bottlenecks. 

Use the following ?printf statement and select the appropriate columns from the Array (see ?rtable_indexing for details on indexing)

    printf("%f\n", dsn[2,1][..,[1,3]]);

The [2,1] selects the Array of data from the dsn structure, the [.., [1,3]] selects all rows and columns 1 (x) and 3 (f'(x)).

Use the following ?printf statement and select the appropriate columns from the Array (see ?rtable_indexing for details on indexing)

    printf("%f\n", dsn[2,1][..,[1,3]]);

The [2,1] selects the Array of data from the dsn structure, the [.., [1,3]] selects all rows and columns 1 (x) and 3 (f'(x)).

How 'bout Zeno's paradox.

How 'bout Zeno's paradox.

Do you mean 2/Pi?

Do you mean 2/Pi?

For a single call to euclid, the recursive version is slower.  However, that isn't how euclid is called in the main loop.  Instead, there are multiple calls to euclid, and each with successively larger values of n.  Because we can quickly compute euclid(s,n+1) from euclid(s,n), the recursive version with the cached result is much faster.  Alas, given how quickly the number of loops (n) increases as q increases, this speedup is not going to be enough. 

For a single call to euclid, the recursive version is slower.  However, that isn't how euclid is called in the main loop.  Instead, there are multiple calls to euclid, and each with successively larger values of n.  Because we can quickly compute euclid(s,n+1) from euclid(s,n), the recursive version with the cached result is much faster.  Alas, given how quickly the number of loops (n) increases as q increases, this speedup is not going to be enough. 

@hirnyk I didn't do anything rigorous, just thought about the problem. I believe that the value should be 2/Pi for any f that is a smooth, nonnegative, monotonic, increasing function.  I assumed that the limit of the mean, as T goes to infinity, should equal the limit of the mean over a fixed interval, as the starting point for that interval goes to infinity.  It isn't hard to see that that mean approaches that of sin(theta) from 0 to Pi.

@hirnyk I didn't do anything rigorous, just thought about the problem. I believe that the value should be 2/Pi for any f that is a smooth, nonnegative, monotonic, increasing function.  I assumed that the limit of the mean, as T goes to infinity, should equal the limit of the mean over a fixed interval, as the starting point for that interval goes to infinity.  It isn't hard to see that that mean approaches that of sin(theta) from 0 to Pi.

Modular multiplicative inverse is the more precise term.

Modular multiplicative inverse is the more precise term.

Note that it isn't just sqrt that will change the expression. Maple will automatically do the same with rational^rational:

 (3/4)^(1/2);
                               1/2  1/2
                              3    4
                              ---------
                                  4