You can use the latex command, but you have to put your data in a Matrix for it to format it as a latex array.

The piecewise integrator seems to have been broken by a change to simplify.  You can access a different integration method with the method option. In this case the fundamental theorem of calculus (ftoc) integrator gets the correct answer.

int(1/A, x=-1..1, method=ftoc);

There is actually a bug in the routine >int/hermiter/horowitzLog it references the global symbol 'x' when it should be referencing a local variable 'x'. You can avoid the error by replacing the x in G with any other symbol e.g.

G := subs(x=x0, G);

. However, this is still not an easy integral, and even with the workaround, the integral hangs for me.

If you are only looking at polynomial or rational functions to solve, it is probably best to just call SolveTools:-SemiAlgebraic directly with all the inqualities (avoiding assumptions). 

> SolveTools:-SemiAlgebraic([-((beta*xi^2 + 2*xi^2 - beta)*(beta - 1)^2/4 = 0,
    xi>0,xi<beta, beta>0,beta<1], {xi, beta});

                                                             1/2 
                  1/2                        ((beta + 2) beta) 
          [[-1 + 2    < beta, beta < 1, xi = --------------------]] 
                                                   beta + 2

which gives you a full case discussion of only the real solutions, if you leave beta out of the variables, it will give you a piecewise:

> SolveTools:-SemiAlgebraic([-((beta*xi^2 + 2*xi^2 - beta)*(beta - 1)^2/4 = 0,
    xi>0,xi<beta, beta>0,beta<1], {xi});
           {                                                    1/2
           {              []                      beta <= -1 + 2
           {
           {                         1/2
           {        ((beta + 2) beta)
           { [[xi = --------------------]]            beta < 1
           {              beta + 2
           {
           {              []                          1 <= beta

I can replicate this bug until Maple 9, but it was fixed in Maple 9.5 (20 years ago!) and all subsequent versions. Seems like just yesterday I was installing the fancy new Maple version 6.

So, there are a lot of complicated solutions in this thread, but the main issue is that the simple recursive implementation of eliminate is not really designed to eliminate n variables from fewer than n+1 equations.  Clearly this example is a special case where it is possible to eliminate three variables from three equations. So, the first thing I tried was to just eliminate two variables and see what we get:

> eliminate({ a^2 = 4*y*z/((x + y)*(x + z)), 
                     b^2 = 4*z*x/((y + z)*(x + y)), 
                     c^2 = 4*x*y/((x + z)*(y + z))}, {x,y});

            2  2      2      2      2
        z (a  c  - 2 a  - 2 b  - 2 c  + 8)
[{x = - ----------------------------------,
                    2  2      2
                   a  c  - 4 a

          2    2    2        2  2      2      2      2
        (a  - b  - c  + 4) (a  c  - 2 a  - 2 b  - 2 c  + 8) z
    y = -----------------------------------------------------},
                    2   2    2    2        2
                   a  (a  - b  + c  - 4) (c  - 4)

                               2    2    2                 2    2    2
    {(a - 2) (a + 2) (a b c + a  + b  + c  - 4) (-a b c + a  + b  + c  - 4)}]

as you can see, the dependency between x,y and z makes it so that z is already eliminated when we eliminate x and y.  The fact that eliminate doesn't recognize this dependency is definitely a weakness, and I have a fix that should appear in the next release of Maple.

This is the sort of problem that SolveTools:-SemiAlgebraic is designed to solve, however, in the 1162 case, it seems the inequalities are very challenging to solve exactly (I stopped it after an hour) and @dharr's semi-numerical solution above is a more efficient option.

My suspicion is that in this case, a proper description of the non-0 dimension components of the Real number solution to the problem is very large.  By computing the complex solutions to the equations and looking at the zero-dimensional ones that happen to be real you get a subset of the solutions much more quickly.
 

For more reliabled performance, it is best to not create formulas first and use := to assign values to the variables.  Either assign the variables first and then combine them in formulas, or use eval() to specialize a symbolic formula.

Either

z := 10*Unit('km');
s := 12*Unit('cm');
lambda := 600*10^(-9)*Unit('m');
theta := s/z;
Diam := 1.22*lambda/theta;        

or

theta := s/z;
Diam := 1.22*lambda/theta;
eval(Diam, {lambda = 600*10^(-9)*Unit('m'), s = 12*Unit('cm'), z = 10*Unit('km')});
 

Doing it in the other other, like in your worksheet, works enough of the time that you end up thinking it's okay, but things get evaluated differently and it ends up being problematic when working with more complicated elements like units

P.S. as of Maple 2018, you can just use with(Units): and it will automatically load the best units handling environment.

There haven't been any significant changes made to the top level isprime command in a long time and not even small ones from Maple 18 to 2017. After the initial trial divisions in isprime, Maple does indeed call mpz_probab_prime_p for gmp_isprime, it just chooses its own value for the 'reps' argument.

These particular forms of RootOf is used internally by a few polynomial solvers.  They aren't recognized by everything that recognizes RootOfs and so they aren't emitted in output by any documented commands outside of a few things in RegularChains.

In general, as a user-level command, RootOf is intended for constructing algebraic numbers for use in doing computation in algebraic number fields (see: https://www.maplesoft.com/support/help/maple/view.aspx?path=evala) and not for solving equations.  With few exceptions, it's always better to call the top level solvers (solve, fsolve) for that.  The code in the question is basically a convoluted way of doing:

If you put your system in matrix form, you can call LinearAlgebra:-LinearSolve with the option free=S to have the free variables be called S[1], S[2], etc.  You can use LinearAlgebra:-GenerateMatrix to put your equations into matrix form if you don't have them there already.  Of course, this depends heavily on what your system of equations looks like.  If it's very sparse or has a lot of parameters, you're probably better off trying to post process the output of solve where the free variables will all show up as xn = xn somewhere in the solutions.

Because of all the parameters, just the Row Eschelon Form of this matrix takes 2 gigabytes to store.  That would put the solution at maybe 30 gigabytes.  Due to the large number of parameters, this problem asked for a very different approach from just trying to write down the closed form of the solutions.

You want to format a string, and then use that string to fill the TextArea

y3 := sprintf("%-2.5s:        %2.5s:     %2.5s\n  %-2.5g:   %-2.5g       %-3.2g\n", z, y, x, y1, x1, z1);
DocumentTools:-SetProperty(TextArea0, value, y3);

This is arbitrary and documented in the sqrt help page:

Try right clicking on the equation choosing "Copy As" and selecting "MathML".  Newer versions of Word knows how to eat MathML.