@nm If you want to save typing, as often seems to be your goal, note that the else NULL in Preben's code is superfluous. All if statements without an else clause have else NULL as default. Also, end if can be changed to fi. The 2,3 can be replaced with op(1,A) to increase the generality of the code. Finally, the two statements can be combined. So, it becomes

ind:= convert(Matrix(op(1,A), (i,j)-> if A[i,j] >= 3 then [i,j] fi), list):

That code involves a user arrow procedure iterated over every element, so Pagan's seq solution is faster:

(n,m):= op(1,A):
ind:= [seq(seq(`if`(A[i,j] >= 3, [i,j], NULL), i= 1..n), j= 1..m)]:

I don't yet know how to make rtable_scanblock work.

Update: I figured out rtable_scanblock, and I give two solutions in an Answer below.

@Stephen Forrest Could you explain your Answer, please? Especially the RegSplit and RegSubs?

@k20057 5 Why can't you plot? I gave you the plotting command before:

plot([lhs,rhs]~(T), style= point);

In the link that you give for the Bose-Einstein statistics, there is a table for 9 quanta of energy distributed among 6 particles. The table gives the expected number of particles with each amount of energy from 0 to 9. The expected numbers for 6 through 9 is small but greater than zero. I don't understand how they cannot be zero. For example, the only way to have a single particle receive all 9 units is for the other 5 particles to receive 0. But that means that there are more than 2 particles with 0 units of energy. How can that be?

Update: I have found the problem. You are confusing Bose-Einstein statistics with Fermi-Dirac statistics. It is the Fermi-Dirac where there can be at most two particles with the same energy. This also explains the problem with my Answer to your last question: You were expecting the Fermi-Dirac numbers, but you gave me the instructions for constructing a Bose-Einstein sample.

@nilssson It is perhaps counterintuitive, but expand is often an important early step in a simplification. Although it tends to make expressions longer, the components tend to be made simpler, which means that subsequent simplifiers such as combine are more likely to be able to do something useful with them.

@Stavros So, do you need me to implement this trivial change in the code?

@gourmelens 

You need to create the animation with the display(..., insequence) command, assign that to A, and then use display again in display([A,fish]);

@gourmelens 

Assign the animation to a variable, say A, then

display([fish, A]);

@Kitonum 

You point is made. At some point the proviso that I mentioned was added. It is clearly stated at ?sort in Maple 18.

Liu,

I split off your Reply as a separate Question entitled "Counting occurences of strings in a file."

The ODE is missing from your Question.

I split this off as a separate question.

Certainly Maple can perform both of these tasks. I can't work on it for several hours yet.

Concerning the second question, do you mean to search for whole lines only? Or may it be necessary to search for substrings within the lines? If the latter, is it possible that there are multiple occurences of the target string within a single line? And in such case should the target be counted multiple times?

@Carl Love And here is the efficient implementation using PolynomialTools:-CoefficientList.

MyCoeffList:= proc(p::polynom, x::name, y::name)
uses PT= PolynomialTools;
local k, L:= map(PT:-CoefficientList, PT:-CoefficientList(p, x, termorder= reverse), y);
    [seq([L[k][], 0$k-nops(L[k])][], k= 1..nops(L))]
end proc:

MyCoeffList(p, x, y);

So, you have about 4 billion elements, each element being a fair-sized linear polynomial. Clearly this cannot be stored in the memory of any normal computer. Fortunately, the coefficients of the polynomials are only 0 or 1. Each polynomial could be represented by a binary number. You have 32 variables, right? So that would be 4-bytes per polynomial, so the minimum memory requirement would be 16Gb. That's assuming that you can get Maple to use only 4 bytes for an integer; I think it might require 8 bytes. Maybe a string representation can be packed into fewer bytes.

Maple's numerical integration seems state-of-the-art to me, but maybe I don't really know what state-of-the-art is. What would you have added?