Daniel, what about runnig Maple 13 in a virtual machine with Fedora 14 as guest OS, say?

@Michael 

See ?gc , it states:

[...]Note, as of Maple 16 the use of gc is discouraged.

Also, the Java GUI may freeze not using all the available memory (cf. e.g. here). So, adding more RAM may not solve the problem...

There are several possible causes of freeze. The Standard GUI is a well known possible cause. I would recommend running your code in the CLI (command line interface) or in the Classic GUI, and observe whether it goes through.

The command restart does not affect some kernel or interface properties, see ?restart.

Probably, the functionality of curtailing the summation at the point at which terms become zero should be part of the missing "SummationTools" package (the analogue of IntegrationTools). It would involve two main parts: 1. deriving the set/predicate for the summation index from the condition that the summand vanishes, and 2. combining this set/predicate with the original summation range for obtaining the new summation range. Hacking a procedure for this second part is rather strigthforward. But the main problem is the first part. For this case of the binomial function, its vanishing arises directly at evaluation under the stated conditions:

> B:=binomial(-n+k-1,-1-n):
> B assuming n::posint, k::nonnegint, k>n;
                                       0

And the fact, read in this sense, is implemented by these lines:

> showstat(binomial,78..79);
binomial := proc(a::algebraic, b::algebraic)
local res, s, c, i, B, AmB, A, fl_res;
global `binomial/a`, `binomial/b`, `binomial/c`;
       ...
  78               NULL
                 end try
               end if
             end if
           elif s = 1 and `tools/type`(A,'integer') and `tools/type`(B,'negint')
then
  79         res := 0
       ...

The problem is that the "reverse" part of this fact seems nowhere implemented. In particular, solve is useless for this purpose:

> solve(B,{k});
                  {k = RootOf(binomial(-n + _Z - 1, -1 - n))}

Presumably, the package MathematicalFunctions should be the place where such an information should be hosted in a centralized location, at disposal for the rest of the system. Somewhat related are the conditions for the validity of the representation in terms of GAMMA functions:

> `convert/GAMMA/from`[binomial]()[2](op(B));
  [[(-n + k)::Not(nonposint), (-n)::Not(nonposint), (k + 1)::Not(nonposint)]]

Yet, using them would be a kind of cheating (besides the inconvenient form of these conditions). So, as I see it, the main issue here is not looking for ways of forcing Maple into doing what is not capable, but looking for ways to complete such missing symbolic computation functionalities. Either by independent development, or by "forcing" Maplesoft management into assigning higher priority to their development.

Probably, the functionality of curtailing the summation at the point at which terms become zero should be part of the missing "SummationTools" package (the analogue of IntegrationTools). It would involve two main parts: 1. deriving the set/predicate for the summation index from the condition that the summand vanishes, and 2. combining this set/predicate with the original summation range for obtaining the new summation range. Hacking a procedure for this second part is rather strigthforward. But the main problem is the first part. For this case of the binomial function, its vanishing arises directly at evaluation under the stated conditions:

> B:=binomial(-n+k-1,-1-n):
> B assuming n::posint, k::nonnegint, k>n;
                                       0

And the fact, read in this sense, is implemented by these lines:

> showstat(binomial,78..79);
binomial := proc(a::algebraic, b::algebraic)
local res, s, c, i, B, AmB, A, fl_res;
global `binomial/a`, `binomial/b`, `binomial/c`;
       ...
  78               NULL
                 end try
               end if
             end if
           elif s = 1 and `tools/type`(A,'integer') and `tools/type`(B,'negint')
then
  79         res := 0
       ...

The problem is that the "reverse" part of this fact seems nowhere implemented. In particular, solve is useless for this purpose:

> solve(B,{k});
                  {k = RootOf(binomial(-n + _Z - 1, -1 - n))}

Presumably, the package MathematicalFunctions should be the place where such an information should be hosted in a centralized location, at disposal for the rest of the system. Somewhat related are the conditions for the validity of the representation in terms of GAMMA functions:

> `convert/GAMMA/from`[binomial]()[2](op(B));
  [[(-n + k)::Not(nonposint), (-n)::Not(nonposint), (k + 1)::Not(nonposint)]]

Yet, using them would be a kind of cheating (besides the inconvenient form of these conditions). So, as I see it, the main issue here is not looking for ways of forcing Maple into doing what is not capable, but looking for ways to complete such missing symbolic computation functionalities. Either by independent development, or by "forcing" Maplesoft management into assigning higher priority to their development.

Yes. The problem, as I see it, is that typically a large number of different TypeMK names could be created that look the same. So, without parsing them, I do not see how you could be sure that they share the same "canonical" representation for interoperation. Presumably, the standard way of handling them would be as in 2D input, passing them through the 2D parser, and operating on the resulting DAGs. 

Do you really mean computing with identifiers, i.e. TypeMK representations of objects?

About the color of brackets, compare the outputs of:

`#mfenced(mfrac(mi("a"),mi("b")))`;
Typesetting:-mfenced(mfrac(mi("a"),mi("b")));

Frequently, along a computation, a lot of shift may occur between the builtin expand routine and the `expand/...` routines in the library which, I guess, do not parallelize. So, isn't there a lot of overhead involved in the process? (pressumably creating and destroyng threads).

I am not sure to understand how your first and last paragraphs match. If an expand operation takes less than a millisecond, say, is it also parallelized?

Frequently, along a computation, a lot of shift may occur between the builtin expand routine and the `expand/...` routines in the library which, I guess, do not parallelize. So, isn't there a lot of overhead involved in the process? (pressumably creating and destroyng threads).

I am not sure to understand how your first and last paragraphs match. If an expand operation takes less than a millisecond, say, is it also parallelized?

This is an interesting phrase!

This is an interesting phrase!

I have tried to get some information about the methods it uses for assesing the quality of a site, but I have received the message "Under construction", at least through  a Google translation to English. Do you have better information on the origin of these estimates?

I think that some additional details or an example is needed. In the following toy example, the entire module is printed only when the argument is explicitly evaluated:

> z:=module() end:
> f:=proc(x)
> x;
> eval(x);
> end proc:
> trace(f):
> f(z);
{--> enter f, args = z
                                       z
                              module()  end module
<-- exit f (now at top level) = module () end module}
                              module()  end module

Yes, the documentation on these features is poor and hard to locate. Find some explanation on the conditional construct in ?patmatch. And on the inertization prefix % in ?value.

Yes, the documentation on these features is poor and hard to locate. Find some explanation on the conditional construct in ?patmatch. And on the inertization prefix % in ?value.