en.wikipedia.org/wiki/Fourier_transform

Irreducible polynomials of degree 6 may or may not be solvable in radicals; even for those that are solvable, convert(..., radical) is not guaranteed to be able to do it.
For example, according to Boswell and Glasser <arxiv.org/abs/math-ph/0504001 > the following sextic is solvable in radicals:

> P:= 36*x^6+36*x^2+18*x+5;

and galois confirms this:

> G:= galois(P);
  with(group):
  DerivedS(permgroup(6,G[5]));

G := "6T11", {"2S_4(6)", "2 wr S(3)", "[2^3]S(3)"}, "-", 48, {"(3 6)", "(1 5)(2 4)", "(2 4 6)(1 3 5)"}

[permgroup(6,{[[3, 6]], [[1, 5], [2, 4]], [[2, 4, 6], [1, 3, 5]]}), permgroup(6,{[], [[2, 5], [3, 6]], [[1, 3, 5], [2, 4, 6]]}), permgroup(6,{[], [[1, 4], [3, 6]], [[2, 5], [3, 6]]}), permgroup(6,{[]})]

But

> convert(RootOf(P,x,index=1), radical);

RootOf(36*_Z^6+36*_Z^2+18*_Z+5,index = 1)

But why do you want to convert the expression to radicals?  The result, for a case such as this, is likely to be an immense mess, much less useful in practice than the RootOf expression.

Irreducible polynomials of degree 6 may or may not be solvable in radicals; even for those that are solvable, convert(..., radical) is not guaranteed to be able to do it.
For example, according to Boswell and Glasser <arxiv.org/abs/math-ph/0504001 > the following sextic is solvable in radicals:

> P:= 36*x^6+36*x^2+18*x+5;

and galois confirms this:

> G:= galois(P);
  with(group):
  DerivedS(permgroup(6,G[5]));

G := "6T11", {"2S_4(6)", "2 wr S(3)", "[2^3]S(3)"}, "-", 48, {"(3 6)", "(1 5)(2 4)", "(2 4 6)(1 3 5)"}

[permgroup(6,{[[3, 6]], [[1, 5], [2, 4]], [[2, 4, 6], [1, 3, 5]]}), permgroup(6,{[], [[2, 5], [3, 6]], [[1, 3, 5], [2, 4, 6]]}), permgroup(6,{[], [[1, 4], [3, 6]], [[2, 5], [3, 6]]}), permgroup(6,{[]})]

But

> convert(RootOf(P,x,index=1), radical);

RootOf(36*_Z^6+36*_Z^2+18*_Z+5,index = 1)

But why do you want to convert the expression to radicals?  The result, for a case such as this, is likely to be an immense mess, much less useful in practice than the RootOf expression.

It's not just sets.  The terms in polynomials can occur in different orders. 

For example, I tried this in several different sessions of Maple 13 Classic:

> expand((1+add(x^i*y^(5-i),i=0..5))^2);

Most of the times I got

           4      2  3      3  2      4        9        8  2
  1 + 2 x y  + 2 x  y  + 2 x  y  + 2 x  y + 2 y  x + 3 y  x

              7  3      6  4      5  5      6  4      7  3      8  2
         + 4 y  x  + 5 y  x  + 6 y  x  + 5 x  y  + 4 x  y  + 3 x  y

              9        5      5    10    10
         + 2 x  y + 2 y  + 2 x  + y   + x

but once

         9        8  2      7  3      6  4      5  5      6  4
  1 + 2 y  x + 3 y  x  + 4 y  x  + 5 y  x  + 6 y  x  + 5 x  y

              7  3      8  2      9          4      2  3      3  2
         + 4 x  y  + 3 x  y  + 2 x  y + 2 x y  + 2 x  y  + 2 x  y

              4        5      5    10    10
         + 2 x  y + 2 y  + 2 x  + y   + x

and once

         6  4      7  3      8  2      9        5      5    10    10
  1 + 5 x  y  + 4 x  y  + 3 x  y  + 2 x  y + 2 y  + 2 x  + y   + x

                4      2  3      3  2      4        9        8  2
         + 2 x y  + 2 x  y  + 2 x  y  + 2 x  y + 2 y  x + 3 y  x

              7  3      6  4      5  5
         + 4 y  x  + 5 y  x  + 6 y  x

It's not just sets.  The terms in polynomials can occur in different orders. 

For example, I tried this in several different sessions of Maple 13 Classic:

> expand((1+add(x^i*y^(5-i),i=0..5))^2);

Most of the times I got

           4      2  3      3  2      4        9        8  2
  1 + 2 x y  + 2 x  y  + 2 x  y  + 2 x  y + 2 y  x + 3 y  x

              7  3      6  4      5  5      6  4      7  3      8  2
         + 4 y  x  + 5 y  x  + 6 y  x  + 5 x  y  + 4 x  y  + 3 x  y

              9        5      5    10    10
         + 2 x  y + 2 y  + 2 x  + y   + x

but once

         9        8  2      7  3      6  4      5  5      6  4
  1 + 2 y  x + 3 y  x  + 4 y  x  + 5 y  x  + 6 y  x  + 5 x  y

              7  3      8  2      9          4      2  3      3  2
         + 4 x  y  + 3 x  y  + 2 x  y + 2 x y  + 2 x  y  + 2 x  y

              4        5      5    10    10
         + 2 x  y + 2 y  + 2 x  + y   + x

and once

         6  4      7  3      8  2      9        5      5    10    10
  1 + 5 x  y  + 4 x  y  + 3 x  y  + 2 x  y + 2 y  + 2 x  + y   + x

                4      2  3      3  2      4        9        8  2
         + 2 x y  + 2 x  y  + 2 x  y  + 2 x  y + 2 y  x + 3 y  x

              7  3      6  4      5  5
         + 4 y  x  + 5 y  x  + 6 y  x

You might try csum in my Maple Advisor Database, www.math.ubc.ca/~israel/advisor

You might try csum in my Maple Advisor Database, www.math.ubc.ca/~israel/advisor

A second-order DE F(x, y, y', y'') = 0 is exact if there is some G(x,y,y') whose derivative is F(x,y,y',y'').  You can find G by integration (typically involving integration by parts).  This reduces the second-order DE to a first-order DE.  So in this case:

ode1:=diff(phi(x),x$2)+1/x*diff(phi(x),x)-phi(x)/x^2=-1/DD*(q*x/2+P/(2*Pi*x)):
ode2:= map(int, ode1, x);

ode2 := 1/x*phi(x)+diff(phi(x),x) = -1/4/DD*q*x^2-1/2*1/DD*P/Pi*ln(x)

A second-order DE F(x, y, y', y'') = 0 is exact if there is some G(x,y,y') whose derivative is F(x,y,y',y'').  You can find G by integration (typically involving integration by parts).  This reduces the second-order DE to a first-order DE.  So in this case:

ode1:=diff(phi(x),x$2)+1/x*diff(phi(x),x)-phi(x)/x^2=-1/DD*(q*x/2+P/(2*Pi*x)):
ode2:= map(int, ode1, x);

ode2 := 1/x*phi(x)+diff(phi(x),x) = -1/4/DD*q*x^2-1/2*1/DD*P/Pi*ln(x)

It seems that there is something subtle at work here.  In Classic, or in Standard with "Maple Standard" typesetting level, the Matrix does show as

[x1 ]
[x2 ]

In Extended typesetting level, it shows as

[ a11 x1 + a12 x2 ]
[ a21 x1 + a22 x2 ]

One thing that works in Extended typesetting level is

> map(eval, gradV);

This is not a question of whether substitutions have occurred (they haven't: the value of gradV is still the same after assigning a value to a11 as it was before), but rather of what level of evaluation is applied to the Matrix elements when the Matrix is displayed.

It seems that there is something subtle at work here.  In Classic, or in Standard with "Maple Standard" typesetting level, the Matrix does show as

[x1 ]
[x2 ]

In Extended typesetting level, it shows as

[ a11 x1 + a12 x2 ]
[ a21 x1 + a22 x2 ]

One thing that works in Extended typesetting level is

> map(eval, gradV);

This is not a question of whether substitutions have occurred (they haven't: the value of gradV is still the same after assigning a value to a11 as it was before), but rather of what level of evaluation is applied to the Matrix elements when the Matrix is displayed.

It would be better if you specified precisely what you meant, rather than having us guess.  My guess is that you're looking for all maps from subsets of B to the power set of A.  Suppose A has m elements and B has n.  The number of maps from a given k-element set to the power set of A (which has 2^m elements) is (2^m)^k = 2^(m*k).  The number of k-element subsets of B is binomial(n,k).
So...

Let's write c + (d-c)*j/10 = t (which will be very close to e).  You're computing (and then plotting)
t^x - x - 1 for x very close to 0.  Now t^x will be close to 1, so you're taking something close to 1,
then subtracting something close to 0, and then subtracting 1.  This is a recipe for large relative
roundoff error due to "catastrophic cancellation". 

If computing with Digits = 10, the roundoff error in t^x might be as much as
5*10^(-10) (i.e with 10 digits you can represent 1 + 10^(-9) = 1.000000001 and 1 + 2*10^(-9)
= 1.000000002 but there are no representable numbers in between).  Subtract x and subtract 1
and you'll still have a roundoff error of about the same absolute magnitude, but since the result
is small the relative error may be quite large.  For t = e you'd have e^x - x - 1 ~= x^2/2, so if
x^2/2 < 5*10^(-10) or so the actual value is completely overwhelmed by the roundoff error.
Thus at x = 10^(-6),  t1 = 2.7182 and t2 = 2.7183 although with exact arithmetic we'd have
 

t1^x =         1.0000009999704
t1^x - x - 1 = -.0000000000295...
t2^x =         1.0000010000072...
t2^x - x - 1 =  .0000000000072...
    

helping you to conclude that t1 < e < t2, with Digits = 10 this becomes

t1^x =         1.000001000
t1^x - x - 1 = 0.000000000
t2^x =         1.000001000
t2^x - x - 1 = 0.000000000

For 0 < x < 10^(-6), there will be some x values where roundoff happens to give us small positive or negative values, but no systematic trend.  Thus for x = 0.3334 * 10^(-6), both t1^x and t2^x would be
1.000000333, both t1^x - x  and t2^x - x would be 0.9999999996, and both t1^x - x - 1 and t2^x - x - 1
would be -0.0000000004.

Now actually plot uses hardware floats when possible, so it's not quite so bad as this (the equivalent of Digits about 14 or 15), but the basic idea is the same.  To get good n digits for e by this method, you'd need to do your calculations with more than 2n digits.

Let's write c + (d-c)*j/10 = t (which will be very close to e).  You're computing (and then plotting)
t^x - x - 1 for x very close to 0.  Now t^x will be close to 1, so you're taking something close to 1,
then subtracting something close to 0, and then subtracting 1.  This is a recipe for large relative
roundoff error due to "catastrophic cancellation". 

If computing with Digits = 10, the roundoff error in t^x might be as much as
5*10^(-10) (i.e with 10 digits you can represent 1 + 10^(-9) = 1.000000001 and 1 + 2*10^(-9)
= 1.000000002 but there are no representable numbers in between).  Subtract x and subtract 1
and you'll still have a roundoff error of about the same absolute magnitude, but since the result
is small the relative error may be quite large.  For t = e you'd have e^x - x - 1 ~= x^2/2, so if
x^2/2 < 5*10^(-10) or so the actual value is completely overwhelmed by the roundoff error.
Thus at x = 10^(-6),  t1 = 2.7182 and t2 = 2.7183 although with exact arithmetic we'd have
 

t1^x =         1.0000009999704
t1^x - x - 1 = -.0000000000295...
t2^x =         1.0000010000072...
t2^x - x - 1 =  .0000000000072...
    

helping you to conclude that t1 < e < t2, with Digits = 10 this becomes

t1^x =         1.000001000
t1^x - x - 1 = 0.000000000
t2^x =         1.000001000
t2^x - x - 1 = 0.000000000

For 0 < x < 10^(-6), there will be some x values where roundoff happens to give us small positive or negative values, but no systematic trend.  Thus for x = 0.3334 * 10^(-6), both t1^x and t2^x would be
1.000000333, both t1^x - x  and t2^x - x would be 0.9999999996, and both t1^x - x - 1 and t2^x - x - 1
would be -0.0000000004.

Now actually plot uses hardware floats when possible, so it's not quite so bad as this (the equivalent of Digits about 14 or 15), but the basic idea is the same.  To get good n digits for e by this method, you'd need to do your calculations with more than 2n digits.

Looks like you left out

> with(plots):