@casperyc 

The item "real time" is real time: the same time that you would measure by means of a stopclock (I have not made the actual experiment, though). While, as I understand it, the item "cpu time" is CPU time in a single processor machine, but it "adds" the CPU time for each processor in a multiprocessor machine. So, presumably, it should be divided by the result of kernelopts(numcpus) to get a meaningful figure.

In my machine, Maple 16 CLI on Linux 32-bit shows:

> L:= RandomTools:-Generate(list(posint, 2^16)):
> data:=CodeTools:-Usage(Threads:-Map(nextprime, L),output='all', quiet=false):
memory used=34.9MB, alloc=44.0MB, time=0.50
memory used=94.5MB, alloc=76.0MB, time=1.67
memory used=317.9MB, alloc=213.1MB, time=3.97
memory used=465.3MB, alloc=277.1MB, time=6.17
memory used=849.3MB, alloc=393.2MB, time=12.17
memory used=1308.9MB, alloc=521.2MB, time=19.38
memory used=1868.8MB, alloc=708.7MB, time=27.91
memory used=2.09GiB, alloc change=0.66GiB, cpu time=32.29s, real time=9.28s
> data[cputime];
                                     32.294
> kernelopts(numcpus);
                                       4
> %%/%;
                                  8.073500000

I agree that, as it stands, this "cpu time" figure makes little sense

@casperyc 

The item "real time" is real time: the same time that you would measure by means of a stopclock (I have not made the actual experiment, though). While, as I understand it, the item "cpu time" is CPU time in a single processor machine, but it "adds" the CPU time for each processor in a multiprocessor machine. So, presumably, it should be divided by the result of kernelopts(numcpus) to get a meaningful figure.

In my machine, Maple 16 CLI on Linux 32-bit shows:

> L:= RandomTools:-Generate(list(posint, 2^16)):
> data:=CodeTools:-Usage(Threads:-Map(nextprime, L),output='all', quiet=false):
memory used=34.9MB, alloc=44.0MB, time=0.50
memory used=94.5MB, alloc=76.0MB, time=1.67
memory used=317.9MB, alloc=213.1MB, time=3.97
memory used=465.3MB, alloc=277.1MB, time=6.17
memory used=849.3MB, alloc=393.2MB, time=12.17
memory used=1308.9MB, alloc=521.2MB, time=19.38
memory used=1868.8MB, alloc=708.7MB, time=27.91
memory used=2.09GiB, alloc change=0.66GiB, cpu time=32.29s, real time=9.28s
> data[cputime];
                                     32.294
> kernelopts(numcpus);
                                       4
> %%/%;
                                  8.073500000

I agree that, as it stands, this "cpu time" figure makes little sense

@AndrewG 

I do not agree with your interpretation. Input mode is not (generically) relevant for output, and the OP's question is about setting boxed matching brackets both in input and output. In the Standard GUI, the underlying representation of 2D input and typeset output is TypeMK. So, probably, the same mechanism should work for both. And I think that there should be a switch between flashing underline and flashing boxes. Perhaps this switch exists, but is not documented...

@AndrewG 

No, the question is clear: "...how to turn this feature on for both input and output?"

@Andriy 

So, if you want a generalization of eliminate, that could handle expressions more complex than names (as second argument), it may be useful to write a procedure. Something along this sketch improving on your approach:

eliminate2:=proc(eq,ex)
local x1,eq1,
r:=ex=x1,
br:=(rhs=lhs)(r):
eq1:=map2(applyrule,r,eq);
eliminate({eq1},x1);
subs(br,eliminate({eq1},x1));
end proc:

eliminate2(a+b*x*conjugate(y)=0,x*conjugate(y));
                                  _
                              [{x y = - a/b}, {}]

@Andriy 

So, if you want a generalization of eliminate, that could handle expressions more complex than names (as second argument), it may be useful to write a procedure. Something along this sketch improving on your approach:

eliminate2:=proc(eq,ex)
local x1,eq1,
r:=ex=x1,
br:=(rhs=lhs)(r):
eq1:=map2(applyrule,r,eq);
eliminate({eq1},x1);
subs(br,eliminate({eq1},x1));
end proc:

eliminate2(a+b*x*conjugate(y)=0,x*conjugate(y));
                                  _
                              [{x y = - a/b}, {}]

As absolute value, or modulus of a complex number, abs(y)>=0. So, the solution must satisfy this constraint, implying some conditions on a and b. But the output of solve contains two solutions of opposite sign, and no condition on a and b is provided:

> solve(%, abs(y));
                                   1/2          1/2
                             (-b a)       (-b a)
                             ---------, - ---------
                                 b            b

Meaning that generically, when these conditions are not satisfied, none of these solutions is correct. Otherwise, only one is, e.g.:

> [eval(%,[a=I,b=1.])],[eval(%,[a=1,b=-1.])];
   [0.7071067812 - 0.7071067812 I, -0.7071067812 + 0.7071067812 I], [-1., 1.]

As absolute value, or modulus of a complex number, abs(y)>=0. So, the solution must satisfy this constraint, implying some conditions on a and b. But the output of solve contains two solutions of opposite sign, and no condition on a and b is provided:

> solve(%, abs(y));
                                   1/2          1/2
                             (-b a)       (-b a)
                             ---------, - ---------
                                 b            b

Meaning that generically, when these conditions are not satisfied, none of these solutions is correct. Otherwise, only one is, e.g.:

> [eval(%,[a=I,b=1.])],[eval(%,[a=1,b=-1.])];
   [0.7071067812 - 0.7071067812 I, -0.7071067812 + 0.7071067812 I], [-1., 1.]

@Carl Love 

However, the piecewise form may be more efficient, e.g. for integration. This is Maple 17 on Linux 32-bit:

> f:=piecewise(x>0 and x<=1, 2*x, x>1 and x<2, 4-2*x, 0);
                          {   2 x          0 < x and x <= 1
                          {
                     f := { 4 - 2 x        1 < x and x < 2
                          {
                          {    0              otherwise
> f1:=JoggedLine(f);
                    f1 := | x | - 2 | -1 + x | + | -2 + x |
> 
> CodeTools:-Usage(int(f,x=-5..5));
memory used=1.42MiB, alloc change=0 bytes, cpu time=28.00ms, real time=29.00ms
                                       2
> CodeTools:-Usage(int(f1,x=-5..5));
memory used=4.82MiB, alloc change=0 bytes, cpu time=88.00ms, real time=86.00ms
                                       2

Also, the integration of abs expressions is notoriously buggy, so that care should be taken.

@Mac Dude 

It may be Maple 401, rather than philosophy...

About what use is good for, besides the examples in ?use, see e.g. these threads:

using `use`

Maple Library Inside A Module procedure

@Mac Dude 

It may be Maple 401, rather than philosophy...

About what use is good for, besides the examples in ?use, see e.g. these threads:

using `use`

Maple Library Inside A Module procedure

One of the problems seems to be in the kernel routine where evalhf(LambertW(...)) gets dispatched. Look at these toy cases:

> evalhf(LambertW(1));
Error, unsupported type `complex(float)` in evalhf
> evalhf(LambertW(1.));
Error, unsupported type `complex(float)` in evalhf

Clearly, the evaluation is not following the normal rules in the float case as there is no problem if done in two steps:

> LambertW(1.);
                                  0.5671432904
> evalhf(%);
                              0.567143290400000000

And certainly, this two-step evaluation shows that the error message is misleading.

So, as far as evalhf could not be avoided, alpha=LambertW(exp(-1)) will not work. And an alternative symbolic form as alpha=RootOf(y*exp(y)-exp(-1),y) also brings problems of its own as RootOf is not being handled, in `dsolve/numeric/make_proc` (see line 13).

One of the problems seems to be in the kernel routine where evalhf(LambertW(...)) gets dispatched. Look at these toy cases:

> evalhf(LambertW(1));
Error, unsupported type `complex(float)` in evalhf
> evalhf(LambertW(1.));
Error, unsupported type `complex(float)` in evalhf

Clearly, the evaluation is not following the normal rules in the float case as there is no problem if done in two steps:

> LambertW(1.);
                                  0.5671432904
> evalhf(%);
                              0.567143290400000000

And certainly, this two-step evaluation shows that the error message is misleading.

So, as far as evalhf could not be avoided, alpha=LambertW(exp(-1)) will not work. And an alternative symbolic form as alpha=RootOf(y*exp(y)-exp(-1),y) also brings problems of its own as RootOf is not being handled, in `dsolve/numeric/make_proc` (see line 13).

@cskoog 

My Pentium 4 32-bit machine has all Maple versions installed from Maple V Release 2 up to Maple 16 in its Windows XP partition. Currently, it is opened up for some cleaning and maintainance that I have not had time to finish, so that I have not installed Maple 17 there yet. The only problem is that Maple V releases 2 and 3 work only in console mode, as there is a well known problem of their GUI for running on "fast" processors. Perhaps a patch could be found, but I have not tried too hard.

@roman_pearce 

It may not be so easy. Modern hardware requires, I think, modern versions of Linux (otherwise, drivers would be missing, etc). But old versions of Maple do not seem to run on modern versions of Linux (at least not in simple way). For instance, on Linux Mint 13 32-bit, Maple 7 GUI (Classic) does not start, sending this error message to the console:

$ /opt/maple7/bin.IBM_INTEL_LINUX/maplew: error while loading shared libraries: 
libstdc++-libc6.1-1.so.2: cannot open shared object file: No such file or directory

Similarly for Maple 7 CLI:

$ /opt/maple7/bin.IBM_INTEL_LINUX/mserver: relocation error: 
/opt/maple7/bin.IBM_INTEL_LINUX/libmaple.so: symbol errno, 
version GLIBC_2.0 not defined in file libc.so.6 with link time reference

Certainly, I have not devoted much effort to find a workaround. On the other hand, Windows may offer a larger version span. In particular, something like Windows XP on not so modern hardware may provide the largest one.