Another problem with the add form like:

sn:= x->Sum( Sum( cos(2*Pi*x* b / a),b=0..a-1),a=1..x):

is that cos terms are generated with diverse fractional multiples of Pi as argument, that are not so easy to simplify, e.g.:

sn(8);
                Pi           2 Pi          2 Pi          3 Pi           Pi
    17 - 2 cos(----) + 2 cos(----) + 2 cos(----) - 2 cos(----) - 2 cos(----)
                5             5             7             7             7

evalf(%);
                                  14.99999999

Here convert(...,radical) is not much useful with denominators 7 as it seems to be restricted to fractions of the form n/120, with n integer. So, following Edgard's line of reasoning, it seems more useful a form like:

sx:=x->convert(numtheory:-divisors(x),`+`):

sx(8);
                                       15

Certainly, assigning 0 for this symbolic sum is the best Maple knows how to do. But I wonder whether this is the state of the art. In particular, a case of the 0/0 problem is involved here, which, I think, could be handled better.

This is a problem in the Maple 16 Standard GUI plot driver. In Maple 16.01 Classic GUI it works OK. Moreover, the plot structures generated by Standard and Classic are almost identical. Both fail, when sent to the plot driver, in Standard, while both work in Classic.

I observe further issues in Standard. As the empty axes box is rotated, some edges of the box disappear within quite large angular ranges.

If suppressing the output by using a colon "solves the problem", meaning that the computation is performed. Then the problem that you describe is of the interface, in displaying the output, not of the Maple kernel in computing the result. And your previous posts suggest that you are using the Standard GUI.

Well, the Standard GUI has severe problems when dealing with large typeset output. So, if you really need seeing such large output, you may try producing it in text form, e.g. running your for loop in the command line interface (CLI), or setting in the Standard GUI the prettyprint level to lprint mode by:

interface(prettyprint=0):

See ?interface. As far as I know, the historysize option of interface applies only to the CLI.

See these threads:

Maple 13 and ubuntu 12.04

[Maple 15][Linux 64Bit] Bug in integration over a domain on Linux amd64

Evaluate integral with polynomial in the denominator

This is a typesetting issue, like in this thread. You may try also producing your output by lprint.

@Axel Vogt 

The integration method that succeeds, hence the form of the result, depends also on the exact form of the integrand after the change theta-2*phi. It happens that PDEtools:-dchange does not split the square root in the denominator, and this form is identified and answered (wrongly) by method ELLIPTICTRIG (as it stands first in the list). On the other hand, IntegrationTools:-Change does split the square root, and this other form is not identified by method ELLIPTICTRIG, so that the method FTOC has its chance to answer, but in terms of elliptic functions:

Digits:=15:
J:=Int(1/(sin(theta)+cos(theta))/sqrt(sin(theta)*cos(theta)), theta=0..Pi/2):
PDEtools:-dchange(theta = 2*phi,J);
           Pi
          ----
           4
         /
        |                               2
        |      ---------------------------------------------------- dphi
        |                                                       1/2
       /       (sin(2 phi) + cos(2 phi)) (sin(2 phi) cos(2 phi))
         0
value(%);
                1/2 1/2      1/2            1/2 1/2                1/2 1/2
- (2 Pi (6 + 2 2   )    - 2 2    Pi (6 + 2 2   )    - 2 Pi (6 - 2 2   )
          1/2            1/2 1/2    /          1/2 1/2         1/2 1/2
     - 2 2    Pi (6 - 2 2   )   )  /  ((6 - 2 2   )    (6 + 2 2   )   )
                                  /
evalf(%);
                                6.56660559364332

IntegrationTools:-Change(J,theta = 2*phi);
            Pi
           ----
            4
          /
         |                                1
      2  |      ----------------------------------------------------- dphi
         |                                          1/2           1/2
        /       (sin(2 phi) + cos(2 phi)) sin(2 phi)    cos(2 phi)
          0
value(%);
memory used=36.5MB, alloc=43.6MB, time=0.52
memory used=113.5MB, alloc=83.8MB, time=1.70
     /             1/2                                  1/2
     |            2        1/2                  1      2
-2 I |2 EllipticK(----) + 2    EllipticPi(- ---------, ----)
     |             2                              1/2   2
     \                                      -2 + 2
                                  1/2                       1/2
        1/2               1      2                    1/2  2
     - 2    EllipticPi(--------, ----) - 2 EllipticF(2   , ----)
                            1/2   2                         2
                       2 + 2
                                           1/2
        1/2             1/2        1      2
     - 2    EllipticPi(2   , - ---------, ----)
                                     1/2   2
                               -2 + 2
                                        1/2 \
        1/2             1/2     1      2    |   /         1/2        1/2
     + 2    EllipticPi(2   , --------, ----)|  /  ((-2 + 2   ) (2 + 2   ))
                                  1/2   2   | /
                             2 + 2          /
> evalf(%);
                                                         -6
                  3.14159265358976 - 0.334713080000002 10   I

There are several different bugs here.The question, in my opinion, is whether there is somebody ready to fix them...

There are several differences between 1-D and 2-D input modes (or languages). and diverse issues for the latter. Opinions are quite varied on these differences and issues. Many threads in this site provide interesting information. Find here some examples:

Delcaring global and local variables inside a procedure

tree

is there a workaround?

solve (...) won't solve but solve(...) without the space will - bug?

error with keyword parameters

Unable to parse local variables

Sum of Odd Numbers

Why is this so stupid ?!!

second derivative in 2d math

dsolve(ODE, y(x), options) - Error, (in dsolve) y(x) and y cannot both appear in the given ODE.

Is this a Bug? 2-D math input

A solution is using a transformation rule. Something like:

A := Sum(lambda[i]*sigma[i]/(lambda[i]+mu-mu*z), i = 1 .. 2):
A1:=convert(A,FormalPowerSeries,z):
coef:=Sum(Sum(u::nonunit(algebraic)*v::`^`(name,name),eq1::equation),eq2::equation)=
Sum(u,eq2):
applyrule(coef,A1);
                     2                      /      mu      \k
                   ----- lambda[i] sigma[i] |--------------|
                    \                       \lambda[i] + mu/
                     )   ------------------------------------
                    /               lambda[i] + mu
                   -----
                   i = 1

Look here for the supported tags.

For such a transformation I would suggest using a procedure like dividend, shown here or here:

dividend(a/(a+b));
                                       1
                                    -------
                                    1 + b/a

The problem here is a 2-D input trap. The third line of your 1-D input shows the name `#mo("⋅",fontstyle = "italic")` which typesets as a dot. If it slipped into your input by use of a menu, my advice is avoid them. Or better yet, avoid the usage of 2-D input altogether. It is full of traps!

I have no much idea about MapleTA, but just as because of curiosity, what do you get if you replace MathML:-ExportPresentation(t^3/t^2) with:

"<math xmlns='http://www.w3.org/1998/Math/MathML'><mfrac><msup><mi>t</mi><mn>3</mn>
</msup><msup><mi>t</mi><mn>2</mn></msup></mfrac></math>"

In the basic form you run its executable command from the OS console (maple in a Linux terminal or cmaple.exe in Windows cmd shell).

This is a peculiar problem of the Standard GUI. This expression can be computed and displayed within a second by using the Classic GUI or the CLI. A workaround in the Standard GUI is using the command

lprint(SC3);

though it is a bit slower.

This is a long standing problem that has never been properly addressed. Certainly, "literal subscripted" names is not the solution as they are not programmatic (namely understood by the C kernel), and there is nothing like "standard subscripts" but indexed names. The thread design mistakes and those linked therein are nice representatives of this recurrent issue. Note, in particular, Jacques' warning about using the macro trick.

My impression is that a real solution should involve a "subscript" constructor of a specific subscripted name DAG, something that the C kernel could understand and handle. Perhaps TypeMK/XML/Java stuff could yet be used for rendering it in the GUI. But I am pesimistic that the current Maplesoft management will ever go that route. By the way, look at Mathematica's Subscript construct.