@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?

@jscottelder 

In my opinion, the Standard GUI is not a good option as a programmer's tool. Indeed, it is not optimized for this usage pattern. And, its inefficienciy and instability issues are well know. So, if your code is for generating random numbers, you are not really using any graphic characteristic of the interface (like typeset output). But you are rather suffering the consequences of its bloated design.

So, my advice is running your code in the CLI which is much more memory efficient and stable, perhaps using an IDE for development. An intermediate approach would be writing your code in an editor and injecting it in the GUI.

@jscottelder 

In my opinion, the Standard GUI is not a good option as a programmer's tool. Indeed, it is not optimized for this usage pattern. And, its inefficienciy and instability issues are well know. So, if your code is for generating random numbers, you are not really using any graphic characteristic of the interface (like typeset output). But you are rather suffering the consequences of its bloated design.

So, my advice is running your code in the CLI which is much more memory efficient and stable, perhaps using an IDE for development. An intermediate approach would be writing your code in an editor and injecting it in the GUI.

Alexandra,

Actually, there is a conflict that has to be resolved. On the one hand, the Community Guidelines state:

No solicitations or advertisements are allowed. These include advertisements for your business or latest get-rich-quick scheme. Such posts add clutter and devalue conversation.

Indeed, spam is a big problem for this site, with very frequent nighty massive attacks. Note, in particular, that there is a "Flag This" link for marking spam posts.

On the other hand, advertisement of third party Maple addons is nevertheless allowed by the administration of this site. Presumably, the rationale is that such addons may be of interest to some members of this community.

So, this is a limbo area that needs action by the administration, in my opinion. May be by issuing some explicit regulation on third party addon advertisements, and/or providing some specific sector of this site for such purpose, as Mac Dude proposes.

Also, in general, keeping this site more or less ordered, by avoiding creation of multiple threads on the same subject, is an important issue. In particular, as searching for some item is already a mess.

So, in the mean time, until some useful guideline on third party advertising is provided, Christopher suggestion of posting in a single thread may be a good measure. And if possible, not posting every two days, as Axel say. Perhaps, a brief comment with a link to a blog of yours elsewhere, or something like that, would be fine for everybody.

Yet, I think that discussions on programming techniques would be OK, even if some of them were at the base of your product.

As C has two sums, A and B, they have to be combined first into a single one. Something that you could do like:

A := Sum(lambda[i]*sigma[i]/(lambda[i]+mu-mu*z), i = 1 .. 2):
B := Sum(lambda[i]*sigma[i]/(lambda[i]+xi+eta-eta*z), i = 1 .. 2):
C := xi*(A-B)/(xi-(mu-eta)*(1-z)):
C1:=convert(combine(C),FormalPowerSeries,z);
applyrule(coef,C1);
  2   /                                 /      mu      \k
----- |        xi lambda[i] sigma[i] mu |--------------|
 \    |                                 \lambda[i] + mu/
  )   |- ------------------------------------------------------- + eta xi
 /    \  (lambda[i] + mu) (eta lambda[i] - xi mu - lambda[i] mu)
-----
i = 1
                       /        eta         \k   /
    lambda[i] sigma[i] |--------------------|   /  (-eta lambda[i] mu
                       \lambda[i] + xi + eta/  /
                2                                       2                 2
     - lambda[i]  mu - 2 lambda[i] mu xi + eta lambda[i]  - eta xi mu - xi  mu
                                         \
                                         |
                             2           |
     + eta lambda[i] xi + eta  lambda[i])|
                                         /

Here coef is an equation specifying a transformation rule from the pattern in the left to the form in the right. The syntax of the pattern is (poorly) explained in ?applyrule and ?patmatch. Basically, it matches by the types of the objects given in the doublecolon (`::`) calls. So, the main trick is writing the "right" doublecolon calls.

I think that PolynomialTools:-CoefficientList is for explicit polynomials, rather than symbolic series as here.

As C has two sums, A and B, they have to be combined first into a single one. Something that you could do like:

A := Sum(lambda[i]*sigma[i]/(lambda[i]+mu-mu*z), i = 1 .. 2):
B := Sum(lambda[i]*sigma[i]/(lambda[i]+xi+eta-eta*z), i = 1 .. 2):
C := xi*(A-B)/(xi-(mu-eta)*(1-z)):
C1:=convert(combine(C),FormalPowerSeries,z);
applyrule(coef,C1);
  2   /                                 /      mu      \k
----- |        xi lambda[i] sigma[i] mu |--------------|
 \    |                                 \lambda[i] + mu/
  )   |- ------------------------------------------------------- + eta xi
 /    \  (lambda[i] + mu) (eta lambda[i] - xi mu - lambda[i] mu)
-----
i = 1
                       /        eta         \k   /
    lambda[i] sigma[i] |--------------------|   /  (-eta lambda[i] mu
                       \lambda[i] + xi + eta/  /
                2                                       2                 2
     - lambda[i]  mu - 2 lambda[i] mu xi + eta lambda[i]  - eta xi mu - xi  mu
                                         \
                                         |
                             2           |
     + eta lambda[i] xi + eta  lambda[i])|
                                         /

Here coef is an equation specifying a transformation rule from the pattern in the left to the form in the right. The syntax of the pattern is (poorly) explained in ?applyrule and ?patmatch. Basically, it matches by the types of the objects given in the doublecolon (`::`) calls. So, the main trick is writing the "right" doublecolon calls.

I think that PolynomialTools:-CoefficientList is for explicit polynomials, rather than symbolic series as here.

That link RegularChains? is broken (at least for me, now). Also, the module (package) RegularChains is located in its own library file RegularChains.mla as far as I can see (e.g. Maple 16.01). And I wonder about the figure of 450 lines for locals and exports definitions, as I see that this module has 1418 members, some of them modules with many members themselves.

Also, what is the format of those .maple files?

In general, I agree with the opinions about advertising made by Axel and Mac Dude. Yet, in my opinion, there are some technical assertions in this post that may be worth discussing (e.g. about preprocessor directives).

It occurs that the first integrator method that "succeeds" in producing an answer is ELLIPTICTRIG, but it produces a wrong answer. On the other hand, method FTOC, which occurs later in the sequence of integrator methods, does produce a correct but even more complicated answer in terms of elliptic functions. This numerically "verified" integral (up to a small imaginary error) can be got by means of the undocumented method _VERIFYFLOAT:

> Digits:=15:
> int(1/(sin(theta)+cos(theta))/sqrt(sin(theta)*cos(theta)), theta=0..Pi/2,method=_VERIFYFLOAT);
memory used=32.8MB, alloc=39.6MB, time=0.54
memory used=112.3MB, alloc=91.6MB, time=1.68
     /                       1/2                                       1/2
     |               1      2      1/2    1/2                  1      2
-2 I |-EllipticPi(--------, ----) 2    + 2    EllipticPi(- ---------, ----)
     |                 1/2   2                                   1/2   2
     \            2 + 2                                    -2 + 2
                      1/2                                1/2
                     2                   1/2     1      2      1/2
     + 2 I EllipticK(----) + EllipticPi(2   , --------, ----) 2
                      2                            1/2   2
                                              2 + 2
                                           1/2 \
        1/2             1/2        1      2    |   /        1/2         1/2
     - 2    EllipticPi(2   , - ---------, ----)|  /  ((2 + 2   ) (-2 + 2   ))
                                     1/2   2   | /
                               -2 + 2          /
> evalf(%);
                                                         -6
                  3.14159265358976 - 0.669426109000004 10   I

I wonder what exactly did Axel say about numerical integrals.

This issue is observable since Maple 11, when the seq modifier was introduced.

This issue is observable since Maple 11, when the seq modifier was introduced.

@kobi 

One of the problems with 2-D input is that what you get may depend on non-recorded GUI interactions (mouse clicks and the like), resulting in a process hard to reproduce. If you have got somehow that "sdot" TypeMK name just by typing "*", it sounds to me as a bug.

@kobi 

One of the problems with 2-D input is that what you get may depend on non-recorded GUI interactions (mouse clicks and the like), resulting in a process hard to reproduce. If you have got somehow that "sdot" TypeMK name just by typing "*", it sounds to me as a bug.

@Kat 

I see. I welcome this vindication of the programmatic approach for students learning Maple. Congratulations to Eli.

Kathleen, 

Maple V? First Leaves? I keep a copy, it is dated 1992...

@Christopher2222 

Yes, common sense says that the default should be false (in not overriding the user-specified horizontal range). But you see, it may take time until it permeates some mind...