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

Sorry, I inadvertantly posted a reply to your message as a reply to the thread parent. Please see below. acer

R:=(n,x)->rem(simplify(HermiteH(n,x),'HermiteH'), x^2-1, x);

R(5,x);

acer

I can't foresee such a basic and longstanding aspect of Maple's evaluation behaviour changing. It doesn't seem like a bug to me, but then I'm used to it. I appreciate the fine level of control it gives. Note that a "full eval" like eval(x) is not always necessary. Eg,

> f:=proc()
> local x,y,z;
> x:=y^2; y:=z; z:=3;
> eval(x,1),eval(x,2),eval(x,3);
> end proc:
> f();

                                    2   2
                                   y , z , 9

A partial eval can allow you to return the value such as an unevaluated function call. If a full-eval were always done then we wouldn't be able to force less than full evaluation. The only locals that I can think of offhand, which get evaluated fully within a proc, are table members in the case that they have been passed (or supplied via lexical scoping) to another inner procedure. For example,

> f:=proc()
> local x,y,z;
> proc()
> x[1]:=y[1]^2; y[1]:=z[1]; z[1]:=3;
> x[1];
> end proc();
> end proc:
> f();

                                       9

Presumably that's because tables have last_name_eval and otherwise usual 1-level eval of locals used as parameters would only give the table name and not even the assigned value. It's as if this exception was coded precisely so that programmers wouldn't have to keep using eval(). (It's a bit weird though, because wouldn't an automatic 2-level eval have also solved the problem without having to wreck the fine control with a full-eval?) Note that globals declared in a procedure always get full evaluation.

> f:=proc()
> global x,y,z;
> x:=y^2; y:=z; z:=3;
> x;
> end proc:
> f();

                                       9

Using globals instead of locals can thus make a procedure less efficient. acer

The existing `convert/base` code in Maple 11, without edits, can also be used to do some conversions to binary significantly faster than is done using Maple 11's `convert/binary`.

Q := proc(n)
parse(cat("11.",
          StringTools:-Reverse(
             StringTools:-Select(
                StringTools:-IsBinaryDigit,
                convert(convert(trunc(evalf[trunc(n/log[2](10.0))+2](
                                         Pi*2^(n-2))),
                                base,2)[1..-3],
                        string))))):
end proc:

On my 64bit Linux machine, the performance crossover between Doug's modified `convert/binary` and `Q` above looks to be about N=25000. Repeat these examples below out of order, or separately. Use the `convert/binary/fraction` routine and its friends from the worksheet. As N gets to 400000 the routine Q gets about 10 times faster.

N := 25000:

gc():
st,ba,bu:=time(),kernelopts(bytesalloc),kernelopts(bytesused):
sol2:=convert(evalf[trunc(N/log[2](10.0))+2](Pi),binary,N):
time()-st,kernelopts(bytesalloc)-ba,kernelopts(bytesused)-bu;
                                                                                
gc():
st,ba,bu:=time(),kernelopts(bytesalloc),kernelopts(bytesused):
sol1 := Q(N):
time()-st,kernelopts(bytesalloc)-ba,kernelopts(bytesused)-bu;

If my sums are right, then one doesn't need more than trunc(N/log[2](10.0))+2 decimal digits in order to be able to obtain N binary digits. The crossover point between Q and the regular system `convert/binary` routines in Maple 11 is about N=200. I didn't look at improving the routines in the worksheet. Perhaps if one could get the address of the DAG of the floating-point number in Maple, and offset it past the DAG header, and copy it byte for byte into a hardware datatype Array, then that could used with hard-coded lookup tables. The lookup tables might contain hardware datatype Arrays as well. acer