It appears as if the comments (starting with # symbol) and the code in the problem area of your Document are being interpreted by Maple as being all on one line. So anything that appeared after the comment symbol, including the code, was being treated as part of one big long comment. As one big comment, it wouldn't execute. At least, that's what it looked like after conversion to 1D input, and that would exactly match the behaviour being seen. I suggest one of two possible ways to get around this problematic behaviour. The first is to write your code in 1D Math input, preferably in a Worksheet not a Document, where such discrepancies are very much rarer. (You can even change preferences, globally for future sessions, for both those aspects.) The second choice is to use text input for comments when using 2D Math and Documents. The max() routine will give the maximum of an expression sequence. For a list L, the expression sequence of its contents is op(L). The printf() routine can format and print things nicely. It works much like it does in the C language. There is an additional qualifier, %a, which stands for algebraic (I think). For your code and list W, it could be like this printf("Max = %a\n", max(op(W))); acer

It appears as if the comments (starting with # symbol) and the code in the problem area of your Document are being interpreted by Maple as being all on one line. So anything that appeared after the comment symbol, including the code, was being treated as part of one big long comment. As one big comment, it wouldn't execute. At least, that's what it looked like after conversion to 1D input, and that would exactly match the behaviour being seen. I suggest one of two possible ways to get around this problematic behaviour. The first is to write your code in 1D Math input, preferably in a Worksheet not a Document, where such discrepancies are very much rarer. (You can even change preferences, globally for future sessions, for both those aspects.) The second choice is to use text input for comments when using 2D Math and Documents. The max() routine will give the maximum of an expression sequence. For a list L, the expression sequence of its contents is op(L). The printf() routine can format and print things nicely. It works much like it does in the C language. There is an additional qualifier, %a, which stands for algebraic (I think). For your code and list W, it could be like this printf("Max = %a\n", max(op(W))); acer

Please ignore. This was an accidental duplicate post. acer

Please ignore. This was an accidental duplicate post. acer

I don't know anything about pasting into mapleprimes, sorry. But the other issue, about what is printed, I can answer. You code does not comprise a "routine". It's not a Maple procedure. It's what's known as "top-level" code. As such, it is governed by Maple's printing rules. These can be changed (at the top-level, and also from within procedures) by using the printlevel setting. See ?printlevel for details. The default is printlevel=1. So, with a for-do and if-then embedded within it, then anything occuring inside the `then` or `else` sections won't normally get printed. But, now, set printlevel:=2 and run that code again. Both the 7 and the 9 are printed. Of course, this is all just control of the display. Assignments and such get done regardless of whether their results are displayed. Some people like to use print or printf statements to get certain things, and only certain things, printed by their code. Others make use of the fact that procedures, when run, will cause their returning values to be printed. I find that sufficient myself, and would recommend using procedures for even small tasks (for this, and lots of other reasons besides). acer

I don't know anything about pasting into mapleprimes, sorry. But the other issue, about what is printed, I can answer. You code does not comprise a "routine". It's not a Maple procedure. It's what's known as "top-level" code. As such, it is governed by Maple's printing rules. These can be changed (at the top-level, and also from within procedures) by using the printlevel setting. See ?printlevel for details. The default is printlevel=1. So, with a for-do and if-then embedded within it, then anything occuring inside the `then` or `else` sections won't normally get printed. But, now, set printlevel:=2 and run that code again. Both the 7 and the 9 are printed. Of course, this is all just control of the display. Assignments and such get done regardless of whether their results are displayed. Some people like to use print or printf statements to get certain things, and only certain things, printed by their code. Others make use of the fact that procedures, when run, will cause their returning values to be printed. I find that sufficient myself, and would recommend using procedures for even small tasks (for this, and lots of other reasons besides). acer

The confusion is quite understandable. The Shift-Enter shortcut is not specific to 2D Math input. acer

Hit Shift and Enter at the same time. See the help-page, ?shortcut_keys,windows acer

Your example has infinitely many solutions. Your result is a compact way of representing them all. Maple's convention for such answers is that _Bxx is Boolean-valued (0 or 1) and _Zyy may be integer-valued. So, your result indicates that any value for x obtained by evaluating that formula at _B15 = <0 or 1> and _Z15 = <some integer> would be a solution. You get to choose which. The tilde (~) is Maple's way of demarking a name that has assumptions on it. The about() command can print the current known assumptions on a name. For example,

> _EnvAllSolutions:=true:

> sol := solve(cos(x) = -1/2);

                    sol := 2/3 Pi - 4/3 Pi _B1~ + 2 Pi _Z1~
 
> seq(about(i),i in indets(sol));
Originally _Z1, renamed _Z1~:
  is assumed to be: integer
 
Originally _B1, renamed _B1~:
  is assumed to be: OrProp(0,1)

The numbers xx and yy in _Bxx and _Zyy are generated automatically by Maple so that the resulting new names don't already have assumptions or assigned values. acer

> q:=y[2]:

> op(1,q);
                                       2

> op(0,q);
                                       y

acer

> q:=y[2]:

> op(1,q);
                                       2

> op(0,q);
                                       y

acer

Your suggestion would make using parts of the OrthogonalSeries package problematic. You may have meant the more special case when n is of type nonnegint. It's still not a great idea, though. With the polynomials expanded, their useful properties (orthogonality, recurrence relation, faster simplification, what have you) are lost. Those properties can be useful even when expansion is possible. Those properties might be very difficult and expensive to ascertain or recognize, with the polynomials expanded. No, it is good to have unexpanded HermiteH, so that SumTools, invlaplace, DEtools, and many more bits of Maple can also make good use of them. I don't think that your sin() example is much good, either. It's not even a true characterization. Consider sin(2*Pi/15). Maple could compute that as being -1/8*2^(1/2)*(5-5^(1/2))^(1/2)+1/8*3^(1/2)+1/8*5^(1/2)*3^(1/2). But it doesn't do that by default. The trig theory that Maple knows can often be used to good effect with it in the sin form. And that's one reason why Maple has `convert`, so that one may have choice. acer

There are routines in Maple which have knowledge of how to manipulate and work with certain classes of polynomial. By that I mean specialized knowledge, which uses theory and is more clever or efficient than what one would get with just the explicit expanded form. In the explicit form, these routines would have no way to immediately recognize the polynomial's special nature. The form HermiteH(n,x) can be regarded as a placeholder for the polynomial, even when n is already given a particular value. Some purposes can use -- or even require -- the expanded, explicit form. And so the help-page for HermiteH gives an example of how to obtain it from the placeholder form. An alternative syntax that might appeal more could be for the HermiteH routine to have an optional 'expanded'=<falsetrue> parameter. It's important to keep in mind that there are usually many more reasons for Maple's behaviour than just the functioning of one's own example at hand. acer

To enter a new line of code, without causing the whole "execution group" to execute, use Shift-Enter instead of Enter. I suspect that what you've been referred to, for Units entry, is one of the Units palettes. The palettes are in a collapsible left-pane. You can customize which palettes are seen using the top-menu View -> Palettes -> Arrange Palettes. The "Units (SI)" palette contains various SI system units as well as a generic Unit() call. This is an easy way to enter units with 2D Math input typesetting. You can also type in calls like Unit('m') and with the context menu convert to 2D Input. Or you can do command-completion on the word Unit typed while in 2D Input mode and select the generic call which should be the first item in the drop-down list that appears. In Maple, units have a multiplicative quality. To attach a unit to an expression pretty much means multiplying it by the appropriate Unit() call. acer

To enter a new line of code, without causing the whole "execution group" to execute, use Shift-Enter instead of Enter. I suspect that what you've been referred to, for Units entry, is one of the Units palettes. The palettes are in a collapsible left-pane. You can customize which palettes are seen using the top-menu View -> Palettes -> Arrange Palettes. The "Units (SI)" palette contains various SI system units as well as a generic Unit() call. This is an easy way to enter units with 2D Math input typesetting. You can also type in calls like Unit('m') and with the context menu convert to 2D Input. Or you can do command-completion on the word Unit typed while in 2D Input mode and select the generic call which should be the first item in the drop-down list that appears. In Maple, units have a multiplicative quality. To attach a unit to an expression pretty much means multiplying it by the appropriate Unit() call. acer