That gets the set, but just encloses the set in a list.  You could try

[op({L[]})];

That gets the set, but just encloses the set in a list.  You could try

[op({L[]})];

That's fine if you don't care what order the elements are in.

That's fine if you don't care what order the elements are in.

If I'm correct that f(z) -> infinity as you approach the singularity, that singularity does have physical meaning.  Perhaps there's something wrong with your mathematical model.  You might "keep maple plotting" in this situation, but the results would be meaningless.

If I'm correct that f(z) -> infinity as you approach the singularity, that singularity does have physical meaning.  Perhaps there's something wrong with your mathematical model.  You might "keep maple plotting" in this situation, but the results would be meaningless.

You can't just use convert(L, list) because the expression sequence L would be considered as several different arguments to convert.  However, you could use

> convert(A(L),list);

(where A is an unassigned name).  The only reason I can think of for wanting to do that rather than using square brackets would be if the [ or ] on your keyboard was broken.

You can't just use convert(L, list) because the expression sequence L would be considered as several different arguments to convert.  However, you could use

> convert(A(L),list);

(where A is an unassigned name).  The only reason I can think of for wanting to do that rather than using square brackets would be if the [ or ] on your keyboard was broken.

Ahh.. the problem wasn't e(z) becoming 0, it was e(z)^2 - 0.27*(1+z)^3 becoming 0.

Unfortunately, it seems to me that f will become unbounded as this approaches 0.  So I really doubt that the question of continuing beyond the singularity can have any meaningful answer.

Ahh.. the problem wasn't e(z) becoming 0, it was e(z)^2 - 0.27*(1+z)^3 becoming 0.

Unfortunately, it seems to me that f will become unbounded as this approaches 0.  So I really doubt that the question of continuing beyond the singularity can have any meaningful answer.

Ah, I wasn't correctly using the flat option.

> MyCperm := proc(L)
    proc(Plt)
        evalindets[flat](Plt, specfunc(anything, {COLOR,COLOUR}),
             c -> subsop(2=op(L[1]+1,c), 3=op(L[2]+1,c),
                  4=op(L[3]+1,c), c))
     end proc end proc;

So for example:

> with(plots): with(plottools):
  Gambia:= display(rectangle([0,0],[3,0.68],colour=green),
  rectangle([0,0.78],[3,1.22],colour=blue),
  rectangle([0,1.32],[3,2],colour=red),
  rectangle([0,0],[3,2]),scaling=constrained,axes=none);  

> Gambia; 

> Cperm([2,3,1])(Gambia); # this is wrong!

> MyCperm([2,3,1])(Gambia); # this is right!

Ah, I wasn't correctly using the flat option.

> MyCperm := proc(L)
    proc(Plt)
        evalindets[flat](Plt, specfunc(anything, {COLOR,COLOUR}),
             c -> subsop(2=op(L[1]+1,c), 3=op(L[2]+1,c),
                  4=op(L[3]+1,c), c))
     end proc end proc;

So for example:

> with(plots): with(plottools):
  Gambia:= display(rectangle([0,0],[3,0.68],colour=green),
  rectangle([0,0.78],[3,1.22],colour=blue),
  rectangle([0,1.32],[3,2],colour=red),
  rectangle([0,0],[3,2]),scaling=constrained,axes=none);  

> Gambia; 

> Cperm([2,3,1])(Gambia); # this is wrong!

> MyCperm([2,3,1])(Gambia); # this is right!

Indeed, the improper integral converges only if theta > 0 and alpha > 0. 

> int(gammadist,x=0..infinity) assuming alpha > 0, theta > 0;

1/(theta^alpha*theta^(-alpha))

> simplify(%);

1

Over the years, Maple has become more careful about checking for convergence.  The downside of this improvement (and yes, it is an improvement) is that you often need to make assumptions on the variables or parameters in order to get the results you want. 

Indeed, the improper integral converges only if theta > 0 and alpha > 0. 

> int(gammadist,x=0..infinity) assuming alpha > 0, theta > 0;

1/(theta^alpha*theta^(-alpha))

> simplify(%);

1

Over the years, Maple has become more careful about checking for convergence.  The downside of this improvement (and yes, it is an improvement) is that you often need to make assumptions on the variables or parameters in order to get the results you want. 

When A and B are Arrays, something like

 if A = B then ...

won't work unless A and B are literally the same (pointers to the same memory location).  What you want to do in this case is check whether the Arrays have the same entries.  You can use IsEqual in the ArrayTools package for this.

The name IsEqual offends the grammarian in me: since it's always used on two or more Arrays, it ought to be called AreEqual.   But I guess it's too late to change that now...