@casperyc 

For me, the redirection operator > has always worked fine (since DOS times to current cmd shell in Windows). Meaning that the syntax cmaple.exe test.mpl > test.out produces a file test.out whose content is (basically) the same as you get in the interactive CLI session (including prettyprinted output). So, I do not know why you get BLANK. If you never did it before, you might check what happens with any other application that writes to standard output.

@Chia 

Because of this bug, the computation by pdsolve returns an intermediate expression in the computation, whose code and algorithms are undocumented for the user. As such, I have no base to say that it is correct.

@casperyc 

Actually, I what I have suggested above is just a sketch. To be completed after what is needed or fits best. Probably, what I would do is sending the output for each maple instance to a file. Something like this (in Linux):

maple a.mpl > a.out &
maple b.mpl > b.out &
maple c.mpl > c.out &

I wonder whether the "true" that you get comes from your Maple code or the OS (Windows) batch file. I am not on Windows at this moment to check. Presumably, doing as above (mutatis mutandis, with @echo off, etc) you should get no additional output to the console, at least from the Maple side.

@casperyc 

Yes, a batch file is a script file. And it's just like running a single line at a time at the command line in interactive mode, but much more efficiently for these purposes.

@nm 

Yes, this help page should be more informative. Yet, the section "Pages That Link to This Page" contains some relevant help links like ?updates,Maple16,memorymanagement and ?updates,Maple17,MemoryRegions . The comment at the end of the latter states:

The explicit call to gc() is used here to illustrate a specific behavior of Maple's memory management system. In general, it is better to allow Maple to decide when to initiate a garbage collection cycle.

But certainly, more information is needed on when this general advice does not hold.

@nm 

An expression sequence is a data structure but not a type in Maple sense (known to the type command), see ?whattype . There are some other "basic" data types like table and rtable.

@nm 

Just reading Jacques' comments in the linked thread, will show you that this is an ancient issue and the probability of an improvement of the latex facility for Maple 19, say, is very slim. So, it seems wiser to look at somewhere else...

@Carl Love 

This thread reminded me about some earlier discussions on the student vs Student issue, like this one.

@Carl Love 

Actually, student[changevar] is an example of a command officially deprecated but whose functionality is not available in the formally superseding package Student (and barely in the rest of the system, it could be said). For instance ?student(deprecated),changevar states:

The change of variables may be implicitly defined, for example,

                          2          2
                         x  + 2 = 2 u 

Actually, the key of the functionality of student[changevar] here comes from student[powsubs], try executing with trace(`student/powsubs`), or execute directly:

> student[powsubs](sinh(x)^2=tanh(x)^2/(1-tanh(x)^2),e);
                                         2
                                 -tanh(x)  + 3
                                 -------------
                                          3
                                   tanh(x)

And note, from ?student(deprecated),powsubs:

The function powsubs differs from subs in that it is defined in terms of algebraic factors rather than in terms of an underlying data structure.

@Mörre Noseshine 

Simply because solve was not originally designed to use such assumptions. It was a feature added lately, in Maple 13, see ?updates,Maple13,symbolics . Actually, it works only for some assumptions, see ?solve,details .

@ecterrab 

Even when you will not provide it, a priori it seems like a fix to this internal routine could be done for several previous versions. Or is there any serious technical impediment?

@Carl Love 

This difference in Maple 16 and earlier may be related to the changes in the memory allocator introduced in Maple 17 as described in ?updates,Maple17,MemoryRegions. Yet, in Maple 17 or 18 on Linux 32-bit I do not get the same result that you show (memory is incompletely cleared):

> version();
 User Interface: 935137
         Kernel: 935137
        Library: 935137
                                     935137
> base:= kernelopts(bytesalloc);
                                base := 6684672
> A:= LinearAlgebra:-RandomMatrix(4000,4000):
memory used=61.6MB, alloc=99.4MB, time=0.63
> kernelopts(bytesalloc) - base;
                                    97558528
> unassign('A'): gc();
memory used=61.6MB, alloc=99.4MB, time=0.73
> kernelopts(bytesalloc) - base;
                                    97558528
> x: y: #Clear the % %% %%% stack.
> gc():
memory used=61.6MB, alloc=38.3MB, time=0.74
> kernelopts(bytesalloc)-base;
                                    33554432
> quit
memory used=61.6MB, alloc=38.3MB, time=0.74

@TomM 

Yes, sadly, the printed output is actually rather decoupled from data structures processed by the (C) kernel, as Jacques has explained in this thread. For instance, the kernel does not know how to handle the Typesetting constructs used internally by the Standard GUI. This decoupling produces many problematic consequences. Your example is just one, and several other cases have been shown here of features that do not work as reasonably expected by the users. Indeed, a unified architecture would have been much better, in my opinion.

@nm 

For 2D display just comment out/do not execute the line:

interface(prettyprint=0):

@Carl Love 

Yes, both, using the CLI and avoid displaying large output, if possible. Note that even with moderate sized results in a number large enough (actually not so large), the Standard GUI typesetter may generate so many objects filling the Java heap that the garbage collection mechanism becomes ineffective, basically paralyzing the virtual machine (producing data loss, etc).

About using the Standard GUI and sending plots to a separate window, I do not think that it makes any difference about making more memory available to the OS. Actually I have this plot option set by default and what I observe (by monitoring Java VMs) is that the plot is handled within the same virtual machine. In particular, I can make rapid changes of the used heap of this virtual machine by rotating with the mouse a 3D plot within this window.