In my opinion, for this purpose, it is easier and more systematic to write code from start in text (.mpl) files. And there are many other reasons and advantages for proceeding this way.

It is happening because no preprocessing procedure for surd exists in the table `limit/mrv/PreProcessTab`. So an error is produced (internally) when looking for a procedure named `limit/preprocess/surd`, finally returning an unevaluated limit .

These are the available entries in `limit/mrv/PreProcessTab`:

indices(`limit/mrv/PreProcessTab`);

[erfc], [sec], [harmonic], [factorial], [Sum], [dawson], [sum], [tan], [sin],

    [Shi], [diff], [GAMMA], [Int], [BesselY], [Si], [floor], [BesselK],

    [arccosh], [RootOf], [Ssi], [polylog], [frac], [arcsinh], [LambertW],

    [conjugate], [round], [ln], [piecewise], [tanh], [int], [sech], [Beta],

    [Ci], [csc], [FresnelS], [lnGAMMA], [arccsch], [FresnelC], [erf], [signum],

    [Re], [coth], [ceil], [exp], [Zeta], [log10], [cosh], [Im], [limit/mrv/EXP],

    [Diff], [cos], [DESol], [max], [Li], [Heaviside], [AiryBi], [trunc], [csch],

    [BesselJ], [Psi], [abs], [cot], [Ei], [csgn], [AiryAi], [erfi], [sinh],

    [arcsech], [binomial], [Dirac], [BesselI], [Chi], [min]

It looks a bit outdated...

Do you mean something like:

eq:=sum(x[i],i=1..5)=Sum(x[i],i=1..5):
applyrule(eq,(x[1]+x[2]+x[3]+x[4]+x[5]+a)/cos(phi));
                        /  5       \    
                        |-----     |    
                        | \        |    
                        |  )       |    
                        | /    x[i]| + a
                        |-----     |    
                        \i = 1     /    
                        ----------------
                            cos(phi)    

No, it is not restricted to polynomial inequalities:

plots:-inequal({sin(x)<1/2,y<abs(cos(x))},x=0..Pi,y=0..2);

 

Certainly, the examples in ?plots,inequal could be a bit more creative...

Some simplifications of the integrand and a very simple change of variable help the integration routines to keep their bearings:

J:=Int(1/(sin(theta)+cos(theta))/sqrt(sin(theta)*cos(theta)), theta=0..Pi/2):
convert(J,phaseamp,theta):
J1:=combine(%,trig);
                       Pi
                      ----
                       2
                     /
                    |                      1
             J1 :=  |      --------------------------------- dtheta
                    |                   Pi               1/2
                   /       sin(theta + ----) sin(2 theta)
                     0                  4
J2:=PDEtools:-dchange(theta = phi-Pi/4,J1);
                           3 Pi
                           ----
                            4
                          /
                         |                  1
                  J2 :=  |      ------------------------- dphi
                         |                            1/2
                        /       sin(phi) (-cos(2 phi))
                           Pi
                          ----
                           4

value(J2);
                                       Pi

In this form, the primitive function becomes expressed in terms of elementary functions:

value(evalindets(J2,`=`,lhs));

                            2 - 4 cos(phi)
1/2 arctan(1/2 -----------------------------------------)
                                  2                  1/2
               (-2 (-1 + cos(phi))  - 4 cos(phi) + 3)
                                   2 + 4 cos(phi)
     - 1/2 arctan(1/2 ----------------------------------------)
                                        2                  1/2
                      (-2 (1 + cos(phi))  + 4 cos(phi) + 3)

So, in regards to the method FTOC, the problem here is at the indefinite integration stage: why the simple primite function is not found in the original variable (just a shift of Pi/4).

Some first steps towards discovering what this error means. A most useful tool here is a debugger as it allows you to stop at the condition generating this error message in line 21 of RegularChains:-TRDisolate_real_zeros  (see ?debugger ,  or try mdcs ), as shown here:

showstat(RegularChains::TRDisolate_real_zeros,21..22);

RegularChains:-TRDisolate_real_zeros := proc(real_point, p_list, R)
local vars, n, lower_rc, lower_cube, p, index_list, interval_list, interval_element, i, inner_real_point, k, rc, mycube, mybox;
       ...
  21     if nops(interval_list) <> nops(index_list) then
  22       error "error in TRDisolate_real_zeros in univariate case"
         end if;
       ...
end proc

And the exception is triggered as the number of operands of these two lists are different. Their evaluation yields this output (in mdcs):

(**) interval_list
[[[0, 0]], [[6231/65536, 12465/131072]], [[12471/131072, 6237/65536]],
[[105/1024, 27/256]], [[39/128, 81/256]], [[21/64, 87/256]], [[15/16, 33/32]],
[[15/16, 33/32]], [[87/64, 45/32]], [[87/64, 45/32]], [[363/256, 183/128]],
[[369/256, 93/64]], [[189/128, 1515/1024]]]

(**)index_list
[7, 3, 4, 5, 5, 4, 4, 4, 6, 4] 

So, the next step is finding why these two lists have different number of operands. Look at the conditional statement starting at line 11:

  11     if nops(p_list) = 1 then
  12       index_list := [seq(1,i = 1 .. nops(interval_list))]
         else
  13       rc := TRDpretend_regular_chain(p,TRDempty_regular_chain(),R);
  14       for interval_element in interval_list do
  15         mycube := interval_element;
  16         mybox := TRDconvert_cad_sample_to_box([rc, mycube],R);
  17         for i to nops(p_list) do
  18           if TRDsign_poly_at_box(p_list[i],mybox,R) = 0 then
  19             index_list := [op(index_list), i];
  20             break
               end if
             end do
           end do
         end if;

Here, p_list is a parameter, and evaluates as a list with 7 operands:

(**) p_list
[beta+1,
beta^20-beta^19-10*beta^18+10*beta^17+45*beta^16-45*beta^15-120*beta^14+120*beta
^13+210*beta^12-210*beta^11-252*beta^10+252*beta^9+210*beta^8-210*beta^7-120*
beta^6+120*beta^5+45*beta^4-45*beta^3-10*beta^2+10*beta+1,
beta^22-11*beta^20+55*beta^18-165*beta^16+330*beta^14-462*beta^12+462*beta^10-
330*beta^8+165*beta^6-55*beta^4+11*beta^2+beta-1,
beta^38-beta^37-19*beta^36+19*beta^35+171*beta^34-171*beta^33-969*beta^32+969*
beta^31+3876*beta^30-3876*beta^29-11628*beta^28+11628*beta^27+27132*beta^26-
27132*beta^25-50388*beta^24+50388*beta^23+75582*beta^22-75582*beta^21-92379*beta
^20+92377*beta^19+92388*beta^18-92368*beta^17-75627*beta^16+75537*beta^15+50508*
beta^14-50268*beta^13-27342*beta^12+26922*beta^11+11880*beta^10-11376*beta^9-
4086*beta^8+3666*beta^7+1089*beta^6-849*beta^5-216*beta^4+126*beta^3+29*beta^2-9
*beta-1, beta-1,
beta^18-beta^17-9*beta^16+9*beta^15+36*beta^14-36*beta^13-84*beta^12+84*beta^11+
126*beta^10-126*beta^9-126*beta^8+126*beta^7+84*beta^6-84*beta^5-36*beta^4+36*
beta^3+9*beta^2-9*beta-1, beta]

so that the computation follows the else part. Then, some leads to follow are: 1. what happens in this part, and 2. why p_list gets this value.

It seems that there is a procedure just for producing an error message:

interface(verboseproc=3):
with(ScientificConstants):
GetElement(Ra,atomicweight);
88, atomicweight = [value = (proc()
option `Copyright (c) 2002 Waterloo Maple Inc. All rights reserved.`;
    error "element is radioactive, most stable or best known isotope has\
     mass number 226"
end proc), uncertainty = undefined, units = 1]

Certainly, this package is quite outdated, see ?Screfs . E.g. it states that CODATA was last accessed eleven years ago...

Yes, this is a bug in singular. It does not check that a variable is dummy. See a simpler example:

singular(Int(1/x,x=1..5));
                                    {x = 0}

No, sqrt(2) can be checked as a positive number. Actually, arbitrary predicates can be used, see ?satisfies . E.g.:

p := proc( s::{positive,satisfies(x->evalf(x)>0)})
    s;
end:

p(2),p(2/3),p(2^(1/2));
                                           1/2
                                  2, 2/3, 2

p(-1);
Error, invalid input: p expects its 1st argument, s, to be of type {positive,
satisfies(x -> 0 < evalf(x))}, but received -1

I find that the package MmaTranslator in Maple 13 and 16 has exactly the same procedures, modules, etc. So, except for changes that may have occured in the code of these members, it seems like there was no significant changes since this package was introduced. Meaning that, rather than improved, it may be even less useful than originally, because of the changes in both languages, as you have described. 

Besides, this translator was rather buggy as introduced, except for the simplest Mathematica constructs. It should be rechecked whether any of those bugs was fixed...

Certainly, the Mathematica language uses a lot of operators that may make its code both compact and cryptic. I find that most of these constructs have an associated function call form that frequently looks rather similar to Maple constructs.

On the other hand, compactness of the code is not necessarily correlated with its efficiency when running. That is, some more verbose Maple code may run much faster than its more compact Mathematica counterpart. Efficiency may depend on the implemented algorithms, data structures, the architecture of the system, etc. This is a matter for comparative reviews.

That kind of Mathematica code can implemented in Maple more or less straightforwardly by using transformation rules and/or procedures (in particular procedures with option overload). It may result a bit lengthier, while "ellegance" is more a subjective issue...

Preben, what kind of answer do you expect? Of course, Bryon will always answer that they have plans, as he did here and so many times in the past. So what?

@Leomur 

OK. The system of solutions is a set of equations. And their rhs' are expressions as in my example above. So, one way to do it is using evalindets, by selecting the equations in this set, and applying the rule to their rhs only. Something as in this toy example:

sol:={x1(t)=cos((k*(m1+m2)/(m1*m2))^(1/2)*t),x2(t)=sin((k*(m1+m2)/(m1*m2))^(1/2)*t)}:
evalindets(sol,equation,x->lhs(x)=applyrule(eq,rhs(x)));
                  {x1(t) = cos(omega t), x2(t) = sin(omega t)}

Note that I am not using your actual example as you have not provided the input that produces it in text form so that we could execute it, and I will not type the output expression from your picture...

For cases like the replacement of radicals as in this example, it is handy using a transformation rule like:

ex:=cos((k*(m1+m2)/(m1*m2))^(1/2)*t);
eq:=(k*(m1+m2)/(m1*m2))^(1/2)=omega:
applyrule(eq,ex);
                                  cos(omega t)

See ?applyrule. Sadly, algsubs is somewhat limited and, in particular, it cannot handle radicals:

algsubs(eq,ex);
Error, (in algsubs) no variables appearing rationally in pattern

For these transformations on expressions you may use collect:

collect(x^6+y*x^4+z*x^2-g*x^4-3*x^6,x);
                       6             4      2
                   -2 x  + (-g + y) x  + z x 

collect(a*cn+w*dn+e*cn+f*dn,[cn,dn]);
                    (a + e) cn + (f + w) dn