Carl, a nice surprise reading your posts here! I hope to read you again also elsewhere.

@acer 

I have not had time to debug this, but what you show suggest that sorting may be an issue for symbolic coefficients. Yet, the example here has numeric coefficients (1/2 and 1/3) and by their permutation I do not observe any difference:

patmatch((1/2)*Zeta^2+(1/3)*Zeta^5, conditional(Zeta^n::posint*y::anything+z::anything, 
n >= 3), 's');s;s:='s':
                                     false
                                       s


patmatch((1/2)*Zeta^2+(1/3)*Zeta^5, conditional(Zeta^n::posint*y::anything+z::anything, 
n <= 3), 's');s;s:='s':
                                      true
                                                   5
                                               Zeta
                          [n = 2, y = 1/2, z = -----]
                                                 3

restart:
patmatch((1/3)*Zeta^2+(1/2)*Zeta^5, conditional(Zeta^n::posint*y::anything+z::anything, 
n >= 3), 's');s;s:='s':
                                     false
                                       s

patmatch((1/3)*Zeta^2+(1/2)*Zeta^5, conditional(Zeta^n::posint*y::anything+z::anything, 
n <= 3), 's');s;s:='s':
                                      true
                                                   5
                                               Zeta
                          [n = 2, y = 1/3, z = -----]
                                                 2

I tend to make the association with other bugs that occur for expressions (or patterns) with similar "symmetric" structure, like a sum of two terms each of which is a name, a product of two factors, etc. May be that both issues (sorting and symmetry) play a role.

@acer 

I have not had time to debug this, but what you show suggest that sorting may be an issue for symbolic coefficients. Yet, the example here has numeric coefficients (1/2 and 1/3) and by their permutation I do not observe any difference:

patmatch((1/2)*Zeta^2+(1/3)*Zeta^5, conditional(Zeta^n::posint*y::anything+z::anything, 
n >= 3), 's');s;s:='s':
                                     false
                                       s


patmatch((1/2)*Zeta^2+(1/3)*Zeta^5, conditional(Zeta^n::posint*y::anything+z::anything, 
n <= 3), 's');s;s:='s':
                                      true
                                                   5
                                               Zeta
                          [n = 2, y = 1/2, z = -----]
                                                 3

restart:
patmatch((1/3)*Zeta^2+(1/2)*Zeta^5, conditional(Zeta^n::posint*y::anything+z::anything, 
n >= 3), 's');s;s:='s':
                                     false
                                       s

patmatch((1/3)*Zeta^2+(1/2)*Zeta^5, conditional(Zeta^n::posint*y::anything+z::anything, 
n <= 3), 's');s;s:='s':
                                      true
                                                   5
                                               Zeta
                          [n = 2, y = 1/3, z = -----]
                                                 2

I tend to make the association with other bugs that occur for expressions (or patterns) with similar "symmetric" structure, like a sum of two terms each of which is a name, a product of two factors, etc. May be that both issues (sorting and symmetry) play a role.

@Doug Meade 

I am one of the few users able to use the Maple Debugger :) However, in general, I prefer using Joe's improved debugger mdcs. Moreover, the Standard GUI has the "feature" that the Maple Debugger opens a graphic interface. But this graphic interface is broken. Hence, using this debugger in Standard is frequently impossible, so that  mdcs becomes the unique possibility for debugging with this interface. And remarkably, the Chapter 16 of the Programming Guide makes its explanation based on the command-line interface of the Maple Debugger, which is only available through the CLI and the Classic GUI.

As he made no mention above...

@Doug Meade 

I am one of the few users able to use the Maple Debugger :) However, in general, I prefer using Joe's improved debugger mdcs. Moreover, the Standard GUI has the "feature" that the Maple Debugger opens a graphic interface. But this graphic interface is broken. Hence, using this debugger in Standard is frequently impossible, so that  mdcs becomes the unique possibility for debugging with this interface. And remarkably, the Chapter 16 of the Programming Guide makes its explanation based on the command-line interface of the Maple Debugger, which is only available through the CLI and the Classic GUI.

As he made no mention above...

It may be worth adding that procedures and modules may have a description clause. Though it is (sadly) removed in the display by showstat, it is shown by some other display options:

> f:=proc()
> description "my description":
>     4;
> end proc:
> 
> showstat(f);
f := proc()
   1   4
end proc
> 
> op(f);
                proc() description "my description"; 4 end proc
> Describe(f);
# my description
f( )

It may be worth adding that procedures and modules may have a description clause. Though it is (sadly) removed in the display by showstat, it is shown by some other display options:

> f:=proc()
> description "my description":
>     4;
> end proc:
> 
> showstat(f);
f := proc()
   1   4
end proc
> 
> op(f);
                proc() description "my description"; 4 end proc
> Describe(f);
# my description
f( )

Yes, this is a well-known bug of 2-D input mode. For this purpose, it is better using 1-D input.

@acer 

Another one is Grid:-g_ssystem. See here:

with(Grid):
showstat(ssystem);

ssystem := proc()
   1   if StringTools[IsPrefix]("Command-line",convert(interface(version),string)) = true 
or evalb(StringTools[Search]("windows",kernelopts('platform')) < 1) then
   2     Grid:-g_ssystem := ssystem
       else
   3     Grid:-g_ssystem := define_external(mrt_ssystem,MAPLE,LIB = "mrt.dll")
       end if;
   4   Grid:-g_ssystem(args)
end proc

@acer 

Another one is Grid:-g_ssystem. See here:

with(Grid):
showstat(ssystem);

ssystem := proc()
   1   if StringTools[IsPrefix]("Command-line",convert(interface(version),string)) = true 
or evalb(StringTools[Search]("windows",kernelopts('platform')) < 1) then
   2     Grid:-g_ssystem := ssystem
       else
   3     Grid:-g_ssystem := define_external(mrt_ssystem,MAPLE,LIB = "mrt.dll")
       end if;
   4   Grid:-g_ssystem(args)
end proc

@acer 

May be that Allan alone, or a few other persons, as most developers are not very fond of documenting. But my question is rather why he had to write such (externally implemented) command.

@acer 

May be that Allan alone, or a few other persons, as most developers are not very fond of documenting. But my question is rather why he had to write such (externally implemented) command.

I fully agree with your appreciation about the value of Maple. My motivations were pretty the same, some 20 years ago...

You may find interesting reading this thread, and links therein, about some GUI issues.

I fully agree with your appreciation about the value of Maple. My motivations were pretty the same, some 20 years ago...

You may find interesting reading this thread, and links therein, about some GUI issues.

@jscottelder 

You are completely right, when dealing with complex results a graphical interface is a big advantage. I know very  well the pain of dealing with ascii output, the only one available then as I began using CAS systems...

The problem is that Maplesoft is not providing a good GUI for programmers and heavy users. Not long ago, Alec put it shortly:

The Classic Maple editor is limited because it is based on a rather old Star Division GmbH (1991-1994) software, which one can see in it's about box (in Help menu.)

The Standard Maple editor is limited because it runs in Java virtual machine - it is not a native application.

One of the design problems in the Standard GUI is that typesetting and computation are interwined. Note also that the 2-D input mode (or language) is particularly inefficient and buggy. Hence, in my opinion, the document mode is the worst option for programming.

I have run your example document many times, and observed that the bulk of the memory consumption, with semicolon at the end of the for loop goes to the Java process. About 20-30 MiB and 0.2s CPU time per run with patterns = 256, compared with some 1-2MiB and 0.07s per run with colon. Even when no output was produced in either case (at least for my settings). For patterns = 4096 and semicolon, I observe an increase of about 280MiB and 2.5s CPU (but a much larger real time).

So, what you are looking for seems to be a command for garbage collection in the Java process.

Now, the "recent" versions of the Maple comprise two main parts, the traditional C subsystem and a Java subsystem grafted onto it. The C subsystem, is the "programatic" part, where commands are processed via the C kernel. The Java subsytem deals e.g with typesetting in the Standard GUI, including 2-D input parsing, and user access to its functionality seems restricted mostly to graphic interactions (menues, palletes, etc).

The C subsystem has the garbage collection command gc (though its usage is discouraged since Maple 16). But there is no such command or equivalent for the Java subsystem, as far as I know. And apparently, after e.g. this site, garbage collection cannot be forced in Java.

Certainly, as acer suggests, you may try running in Classic, but only on Windows. But note his recent comment on the destiny of this interface.

May be that acer could make the code of your example much more efficient, so that memory problems are pushed far away for this particular case. But is this the solution to the GUI conundrum?