@Carl Love 

And what time do you get in that system for Maple 16.02 or any previous versions? I have read elsewhere of a timing similar to yours (40s) in Maple 17 on Win 7, and about 10s in earlier versions. So, there may be several issues around. I will check later on Linux 64-bit.

@Carl Love 

And what time do you get in that system for Maple 16.02 or any previous versions? I have read elsewhere of a timing similar to yours (40s) in Maple 17 on Win 7, and about 10s in earlier versions. So, there may be several issues around. I will check later on Linux 64-bit.

@Carl Love 

The method used by default is elliptic, which internally calls ftoc. In Maple 16.02:

> value(subsindets(K,specfunc(anything,Int),z->Int(op(z),method=ftoc))):
> evalf(%);
memory used=28.1MB, alloc=40.5MB, time=0.44
                                                     -9
                       0.3224464891 - 0.6156634373 10   I
> value(subsindets(K,specfunc(anything,Int),z->Int(op(z),method=ftocms))):
> evalf(%);
                                                     -9
                       0.3224464885 - 0.6772297809 10   I
> value(subsindets(K,specfunc(anything,Int),z->Int(op(z),method=elliptic))):
memory used=110.1MB, alloc=87.2MB, time=1.62
memory used=315.9MB, alloc=212.3MB, time=4.60
memory used=520.9MB, alloc=212.3MB, time=7.46
> evalf(%);
                         0.3224617778 + 0.5553603413 I

By the way, a generalization of value that adds options would be very handy, isnt't it?

A line to pay attention is this one:

> infolevel[IntegrationTools]:=8:
> value(subsindets(K,specfunc(anything,Int),z->Int(op(z),method=elliptic))):
[...]
Definite Integration:   Trying method elliptic.
Definite Integration:   Integrating expression on t=2*3^(1/4)/(1+3^(1/2))..2*2^(1/2)*(3^(1/2)*(2+2^(1/2)))^(1/2)/(2^(1/2)+2+2*3^(1/2))
[...]

as these integration limits go to the "border" of the analytic region (if the integrand were the same):

> evalf(2*3^(1/4)/(1+3^(1/2)));
                                  0.9634330438
> evalf(2*2^(1/2)*(3^(1/2)*(2+2^(1/2)))^(1/2)/(2^(1/2)+2+2*3^(1/2)));
                                  0.9999736968

On the other hand the computation of this integral in Maple 17.01 by method elliptic, or equivalently leaving the default, does not finish here (on Linux 32-bit) in any reasonable time. What version have you used?

@Carl Love 

The method used by default is elliptic, which internally calls ftoc. In Maple 16.02:

> value(subsindets(K,specfunc(anything,Int),z->Int(op(z),method=ftoc))):
> evalf(%);
memory used=28.1MB, alloc=40.5MB, time=0.44
                                                     -9
                       0.3224464891 - 0.6156634373 10   I
> value(subsindets(K,specfunc(anything,Int),z->Int(op(z),method=ftocms))):
> evalf(%);
                                                     -9
                       0.3224464885 - 0.6772297809 10   I
> value(subsindets(K,specfunc(anything,Int),z->Int(op(z),method=elliptic))):
memory used=110.1MB, alloc=87.2MB, time=1.62
memory used=315.9MB, alloc=212.3MB, time=4.60
memory used=520.9MB, alloc=212.3MB, time=7.46
> evalf(%);
                         0.3224617778 + 0.5553603413 I

By the way, a generalization of value that adds options would be very handy, isnt't it?

A line to pay attention is this one:

> infolevel[IntegrationTools]:=8:
> value(subsindets(K,specfunc(anything,Int),z->Int(op(z),method=elliptic))):
[...]
Definite Integration:   Trying method elliptic.
Definite Integration:   Integrating expression on t=2*3^(1/4)/(1+3^(1/2))..2*2^(1/2)*(3^(1/2)*(2+2^(1/2)))^(1/2)/(2^(1/2)+2+2*3^(1/2))
[...]

as these integration limits go to the "border" of the analytic region (if the integrand were the same):

> evalf(2*3^(1/4)/(1+3^(1/2)));
                                  0.9634330438
> evalf(2*2^(1/2)*(3^(1/2)*(2+2^(1/2)))^(1/2)/(2^(1/2)+2+2*3^(1/2)));
                                  0.9999736968

On the other hand the computation of this integral in Maple 17.01 by method elliptic, or equivalently leaving the default, does not finish here (on Linux 32-bit) in any reasonable time. What version have you used?

@Bendesarts 

Hello, ?worksheet,documenting,insertexgroup (somewhat) explains it:

An execution group consists of Maple input with its corresponding Maple output. It is characterized by a large square bracket, called a group range, at the left.

So, each execution group can have many input lines, and the multiple line comment (* ... *) can be used for selecting out of these input lines, but only for them. That is, this comment has to be closed within a single execution group (which could contain all the input of your worksheet, by the way). A multple line comment opened in an execution group and closed in a later one will not work, producing an error like Error, `*` unexpected.

Download comment.mw

@Bendesarts 

Hello, ?worksheet,documenting,insertexgroup (somewhat) explains it:

An execution group consists of Maple input with its corresponding Maple output. It is characterized by a large square bracket, called a group range, at the left.

So, each execution group can have many input lines, and the multiple line comment (* ... *) can be used for selecting out of these input lines, but only for them. That is, this comment has to be closed within a single execution group (which could contain all the input of your worksheet, by the way). A multple line comment opened in an execution group and closed in a later one will not work, producing an error like Error, `*` unexpected.

Download comment.mw

Yes, multiple lines, but only within a single execution group. If the section has multiple execution groups, it has to be done for each, not very handy if many...

Yes, multiple lines, but only within a single execution group. If the section has multiple execution groups, it has to be done for each, not very handy if many...

As I have told it here several times before, I have used several CAS, in particular Mathematica before Maple, and made comparisons. But my story goes over twenty years ago...

Since 1987 to 1990 I have used Reduce, as it was the standard system among my relativist colleagues. At that time I had to use it in the shared department XT machines, what severely limited the size of computations, or for special cases I went to a VAX machine in computer center. But my problem was programming which had to be made in Lisp beyond some elementary tasks. And despite my efforts, I could not made sense of Lisp. 

In early 1991, we got the first PC in our group, a 286 machine. Soon I got a copy of Derive. It was very good piece of software and run very nice on that machine, but it had no programming language...

Some months later Mathematica spread among physicists here from their colleagues in the US. It was Mathematica 1 using a CLI. For me square brackets were fine as I have always used US keyboards. No problem either with capitalized names. The interesting thing was that it had a programming language but the problem was that it consumed a lot of memory. And understanding large complex output expressions was a mess. I had to convert them to TeX, save to a file and run in TeX...In 1993 we got a 386 machine and soon after I installed Windows 3.1. And at that time Mathematica 2 spread here. It had a GUI, but it was an even larger memory hog: hardly it worked with less than 8MB RAM, a lot then, at least here. This GUI was somewhat primitive to my taste as in rotation of 3D plots only the bounding box was shown. But the worst problem for me was the programming language. Even if we purchased the bulky Mathematica Book, and stayed a long time studying it, I could not make sense of its functional style programming language either.

Then, at mid 1993 a Mexican colleague introduced me to Maple. It was Maple V R2 on a Mac. Back at home I began trying its Windows version. It had a tiny and nice GUI that run fine with 2MB RAM, so that I could run much larger calculations. Also 3D plots were visible as rotated, and they could be rotated with the cursor arrows! It had also a simple programming language quite similar to what I knew then (BASIC-like). So, quickly I switched to Maple, and by mid 1994 I became Maplesoft Ambassador in Argentina.

When making presentations of Maple, the first question was systematically: how does Maple compare with Mathematica? So, I stayed several years comparing them. But this is matter for another chapter...

Back to the present, I may wonder what I would have chosen with the current Mathematica and Maple? A few hints: the programming languages are more or less the same as then. But frankly, the Standard GUI now takes the place of the memory hog... 

@Andriy 

Indeed, that error should be corrected. But, if you track this site (and elsewhere) you will find many complains about this problem along the years, with no result. Hence, it is unclear whether it will be fixed, and if so when. So, what will you do in the mean time? My choice is avoiding the Standard GUI as far as possible.

The opinion of the developers (or Maplesoft management) on this issue has never been expressed openly as far as I can remember, so it is a subject of speculation. I would find it surprising that they have not fixed this problem if it were easy to solve. Then, my guess goes that fixing it is not easy. Note, as another example, that they needed some 6 years wrt the launch of Mathematica's Manipulate for providing a version of Explore somehow similar. I also wonder why so long, given that it is a key competitive item.

So, my main conjecture is that the key problem has been the choice of Java as the base for the development of the Standard GUI and part of the system. Here I have asked openly about the technical reasons explaining this decision to start and keep using Java, given that better alternatives exist. After near three years I have not seen any answer. So, I may fairly conclude that there was no good reason for this decision.

Running your example in Maple 17.01 Standard GUI on Linix Mint 13 32 bit, I have got for the equivalent java process these numbers (in MIB): 104.8 (start), 114.0, 141.7, 167.0 , in general agreement with your observations. For comparison, I have run this same example in the CLI (same platform), and found at the start for these two processes: cmaple 320KiB, mserver 4.1 MiB. After the first run, they became 356KiB, 33.7MiB. And then, for each new run cmaple increases in about 20KiB and mserver stays the same at 33.7MiB. 

My conclusion is: if your actual code is like in this example, where you are not really using any 2D typesetting for output or plots, I do not see any advantage in using the Standard GUI. A critical value of about 1GB is well known for the Java process. Actually the Java 6 that Standard GUI uses. It seems that Java 7 does not suffer this restriction.  

@erik10 

Not a wonder, but useful information on several data structures (lists, sets, rtables, etc) is available in the Chapter 4, Basic Data Structures,  of the Programming Guide ( ?ProgrammingGuide,Chapter04 ).

@Vladimir K. 

Apparently, the incomplete beta function is not implemented in Maple. It should be done first.

@Vladimir K. 

Apparently, the incomplete beta function is not implemented in Maple. It should be done first.

@erik10 

I also agree. There are several other areas that need better documentation. For instance evaluation contexts, like the boolean evaluation context, that occurs in a conditional statement or in the evalb command, vs the normal evaluation context. They need higher profile. You will find about them if you read carefully ?evalb or ?if , but you need to read carefully...

Another area severly under-documented is functional style programming ( `[]` and the like). As you say, this style of programming is both more powerful and more cryptic than "ordinary" programming style, hence the subject for more advanced users. But where do they find documentation on this subject? Certainly, this site contains much more information (this thread is an example).

Finally, possibly as a guide for the future (including other areas also poorly documented), I suggest keeping a link to the thread Modern Advanced Maple and its parent Maple 401.